Re: JDBC, prepared queries, and partitioning

Oliver Jowett <oliver@opencloud.com> writes:
> Another possibility is to make the unnamed statement behaviour in the
> server more aggressive.

Upthread I suggested making that conditional on a GUC variable ...
does that seem reasonable?

We've touched on how a "clean" solution to this would require a protocol
change, but I'm not convinced that a change at the protocol-message
level is all that great a solution.  That way means that only the lowest
layer on the client side has any direct access to the options; and that
layer is really the least likely to understand what the best choice for
a given query is.  So you immediately are faced with having to design
client-side APIs to expose the behavior upward.  For instance JDBC would
need to expose an API to calling applications, and the same for libpq
and other client libraries.

If we drive this off a GUC variable then the extra signaling is already
solved, or at worst soluble with a general-purpose API addition that can
address other issues too.

            regards, tom lane