Re: NOT EXIST for PREPARE

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: NOT EXIST for PREPARE
Дата
Msg-id CAHyXU0zbchQMMrf2u1N4MaOs7Fdek_jDXwSNX+BPTDjURUzWWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NOT EXIST for PREPARE  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Ответы Re: NOT EXIST for PREPARE  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Список pgsql-hackers
On Wed, Mar 23, 2016 at 1:15 PM, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
> Merlin>No one is arguing that that you should send it any every time (at
> least -- I hope not).
>
> Well, what is your suggestion exactly?
>
> pgjdbc is NOT using "prepare ..." sql command.
> I'm inclined to suppose, it will not use "prepare..." even after your fix.

Maybe so (note, the fix is not mine).  I guess better stated, the
proposed would allow use of server side prepared statements with JDBC.

> Merlin>Again, not in pooling scenarios
> Merlin>The problems integrating server side
> Merlin>prepared statements with pgbouncer are well known.
>
> I'm afraid, they are not.

yes, they are.   see:
https://pgbouncer.github.io/faq.html#how-to-use-prepared-statements-with-session-pooling

There are numerous pages on the web suggesting to DISCARD ALL in
transaction mode which is incredibly wasteful in the case of prepared
statements...so much so you're better off not using them if you can
help it.  With proposed, the application can simply prepare after
opening the 'connection' and not have to worry about handling the
error or scope.

> Your words are "This feature should be immediately be incorporated
> by the JDBC driver" yet you have not raised that subject on pgsql-jdbc
> mailing list/github issue. That is not very fair.

That's fair. Although there was a very long standing issue where jdbc
would try to prepare 'BEGIN' in such a a way that it could not be
disabled -- that was fixed.

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Relation extension scalability