[WorldWideWayne]

Composing SQL strings at runtime should be the very last resort in my opinion.

This is what stored procedures and parameterized queries are for. Even if I am going to do dynamic SQL, I do it in a stored procedure if I can.

[bayesianhorse]

Then you are one of the rare SQL-englightened beings.

I still don't see how you can pass user input from, say, a python string into a stored procedure call without worrying about injections. Or converting between your app's data structures and whatever string is necessary for your stored procedure.

[danneu]

Your driver should be able to handle parameterized queries for you.

    query('SELECT * FROM users WHERE id = ANY ($1::int[])', [1, 2, 3]);
    query('SELECT * FROM users WHERE lower(uname) = lower($1)', 'foo');

Where's the injection vulnerability?

[bayesianhorse]

So I may not be an SQL expert, but why would it be difficult to produce an injection string for $1? Of course, if you supply it "guaranteed" integers, then you can't. Injections normally happen with user inputs, not constants.

[WorldWideWayne]

Because SQL query compilers generally don't execute the parameters. They do not just concatenate the given parameter strings into the query template and then run that. Instead, parameters are always treated as parameters, the query template is compiled and the parameters are passed into that compiled representation of the query where they are simply regarded as variables, not eval'd.

[PuercoPop]

lookup prepared statements.