Re: JDBC, prepared queries, and partitioning - Mailing list pgsql-jdbc

From Tom Lane
Subject Re: JDBC, prepared queries, and partitioning
Date
Msg-id 1442.1202968766@sss.pgh.pa.us
Whole thread Raw
In response to Re: JDBC, prepared queries, and partitioning  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: JDBC, prepared queries, and partitioning  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-jdbc
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

pgsql-jdbc by date:

Previous
From: "Stephen Denne"
Date:
Subject: Re: JDBC, prepared queries, and partitioning
Next
From: Oliver Jowett
Date:
Subject: Re: JDBC, prepared queries, and partitioning