Add support for parametrized queries

Hello,

Props for this wonderful tool!

My understanding is that the end product for the user is always the SQL string as returned by calling str on a Query object. Such string can then be passed to whatever database interface the user is using. However, SQL interfaces also accept so-called parametrized queries, where the input isn’t a single SQL string, but rather a string containing placeholders alongside a tuple containing values to replace the placeholders with. Parameterized queries are very important as they’re the only working solution against SQL injection.

The interface could be improved such that the Query object would have two properties statement and values corresponding respectively to the parametrized statement and the values for this statement. The behavior of str would still be relevant as it’s always useful to know what a query looks like even when parametrized, although its output should be documented as insecure with unstrusted data.

[grigi]

I’m looking at adding parametrised query support. My planned implementation is something along the lines of:

Instead of calling query.get_sql() (or str(query)) instead add a query.get_parametrised_sql() which would return Tuple[str, List], and leaves PyPika to return the objects in the right order, so we can just do an execute(sql, *params)

The reason is that the way PyPika is used (in the monoid pattern) order of parameters is only determined at evaluation time, and is dependant on the dialect. I’d rather not duplicate that logic, prone to forward compatibility issues etc… We hand the objects to pypika, and it hands them back to us in the right order with the equivalent sql.

Is there anything I’m overlooking @twheys ?

[twheys]

Thanks for raising this ticket. Can definitely do something like that in the near future.