Re: [HACKERS] Cached plans and statement generalization

On 09/07/2019 23:59, Konstantin Knizhnik wrote:
> Fixed patch version of the path is attached.

Much of the patch and the discussion has been around the raw parsing,
and guessing which literals are actually parameters that have been
inlined into the SQL text. Do we really need to do that, though? The
documentation mentions pgbouncer and other connection poolers, where you
don't have session state, as a use case for this. But such connection
poolers could and should still be using the extended query protocol,
with Parse+Bind messages and query parameters, even if they don't use
named prepared statements. I'd want to encourage applications and
middleware to use out-of-band query parameters, to avoid SQL injection
attacks, regardless of whether they use prepared statements or cache
query plans. So how about dropping all the raw parse tree stuff, and
doing the automatic caching of plans based on the SQL string, somewhere
in the exec_parse_message? Check the autoprepare cache in
exec_parse_message(), if it was an "unnamed" prepared statement, i.e. if
the prepared statement name is an empty string.

(I'm actually not sure if exec_parse/bind_message is the right place for
this, but I saw that your current patch did it in exec_simple_query, and
exec_parse/bind_message are the equivalent of that for the extended
query protocol).

- Heikki