Re: JDBC, prepared queries, and partitioning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: JDBC, prepared queries, and partitioning
Дата
Msg-id 1442.1202968766@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: JDBC, prepared queries, and partitioning  (Oliver Jowett <oliver@opencloud.com>)
Ответы Re: JDBC, prepared queries, and partitioning  (Oliver Jowett <oliver@opencloud.com>)
Список 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 по дате отправления:

Предыдущее
От: "Stephen Denne"
Дата:
Сообщение: Re: JDBC, prepared queries, and partitioning
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: JDBC, prepared queries, and partitioning