Can SQL statement splicing support placeholder rules other than question marks?

[yimuysl001]

Is your feature request related to a problem? Please describe.
1.有些时候sql语句中本来就包含问号字符，但是使用db.query后会将不想转义的问号替换掉导致sql执行出错；
2.另外sql填充过程中，可能存在多个地方重复填充一个值的情况，使用问号占位会让入参有很多重复值，入参会很长，容易错行；
3.期望自定义sql中能够允许注入sql,希望能通过占位的方式添加sql要查询的表，目前只能通过字符拼接的方式来处理,自定义语句处理会很割裂。如果担心sql注入，那字符串直接拼接也是避免不了的。
Describe the solution you'd like
希望有类似java那种 通过 ${} #{} 占位的方式来完整语句的拼接，可以选择是否需要给填充参数添加引号。

Describe alternatives you've considered
或者能添加相应接口，允许自定义相关注入规则

Additional

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Is your feature request related to a problem? Please describe.

1. Sometimes the sql statement originally contains the question mark character, but after using db.query, the question mark that does not want to be escaped will be replaced, causing sql execution errors;
2. In addition, during the sql filling process, a value may be filled repeatedly in multiple places. Using question marks as placeholders will cause many repeated values ​​​​in the input parameters. The input parameters will be very long and it is easy to make wrong rows;
3. It is expected that the injection of SQL can be allowed in the custom SQL. It is hoped that the table to be queried by the SQL can be added through placeholders. Currently, it can only be processed through character splicing, and the custom statement processing will be very fragmented. If you are worried about SQL injection, direct string concatenation is unavoidable.
   Describe the solution you'd like
   I hope there is a method similar to Java that uses ${} #{} placeholders to splice complete statements, and you can choose whether to add quotation marks to the fill parameters.

Describe alternatives you've considered
Or you can add corresponding interfaces to allow customization of relevant injection rules.

Additional