Re: NOT EXIST for PREPARE - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: NOT EXIST for PREPARE
Date
Msg-id CAHyXU0zbchQMMrf2u1N4MaOs7Fdek_jDXwSNX+BPTDjURUzWWw@mail.gmail.com
Whole thread Raw
In response to Re: NOT EXIST for PREPARE  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Responses Re: NOT EXIST for PREPARE
List 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 by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Next
From: Robert Haas
Date:
Subject: Re: Relation extension scalability