[tolmasky]

Sincere question: doesn't the use of template strings increase the possibility of injection where none would theoretically be possible in the non-string version of the API? Not super familiar with the intended purpose of sqorn, hence the real question, but I think part of the goal of query builders can be to very specifically constrain the possible generated output statically.

So, for example in your example above, if I had tied the age parameter to some input box, it is now theoretically up to the caller to sanitize age and make sure the user doesn't type "10 || 1 = 1" or something. This as opposed to say, doing .where(less_than(identifier("age"), input)), where you can absolutely know that if input is not an int you can safely throw. I am basically making the same injection question that's existed forever which is that if you deal at the coarseness of string parsing, you lose the information of what is user generated and what is programmer generated.

[olooney]

Putting a function in front of a backtick string replaces normal string introplation: instead of the default behavior, the function before the backtick string gets passed the literal pieces of the template string and ${} values explicitly and separately. Instead of returning an interpolated string, the function can return whatever it wants. In sqorn's case, it returns an Object with separate keys for sql and and values. When the time comes to actually execute a query, sqorn passes these objects to database backends with positional placeholders in the SQL ($1, $2, $3, etc.) and the values as positional bound parameters. This is a safe way to prevent SQL injection.

[tolmasky]

Excellent, completely answers my question!