> Where I think JDBC (and maybe pgbouncer) is going wrong with this, is > they don't make (allow for) proper use of the "unnamed prepared > statement" which: "...lasts only until the next Parse statement > specifying the unnamed statement as destination is issued." [2] The > code does have oneShot in the parse/bind/execute path so it is > recognized...at least in JDBC.
The driver does use the unnamed statement for pretty much everything until we see the same statement being used prepareThreshold times. Then we switch to a named statement.
Session configuration. If you are using a pooler mode that simply doesn't play nice with named prepared statements you must configure JDBC to not use them (ever) and use only the unnamed prepared statement for parse/bind/execute. The interleaving you want to do is simply not possible (or, rather, you will not get the benefit of actually having the prepared statement saved in a cache for re-use, it will be re-parsed every time).
This seems better than nothing given lots of uses of prepared statements are simply to get access to the extended query protocol's parse/bind/execute. It is quite possible an even better solution exists if pgJDBC and pgbouncer cooperate and design and implement something to overcome this complaint. I'm not going there myself (not that I'm implementing this suggestion) as this solution seems simpler and sufficiently effective for the majority of use cases. It also likely doesn't impose any kind of constraints (especially as this is basically implementation details + configuration, not code-level API changes) on a more nuanced solution.
There are a number of other session settings that we can't really track either.
