Re: NOT EXIST for PREPARE

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote:
> > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > Hi,
> > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote:
> > >> Do I understand correctly the only way know availability PREPARE it will
> > >> appeal to pg_prepared_statements?
> > >> I think this is not a good practice. In some cases, we may not be aware of
> > >> the PREPARE made (pgpool). Moreover, it seems popular question in the
> > >> Internet: http://stackoverflow.com/questions/1193020/php-postgresql-check-if-a-prepared-statement-already-exists
> > >>
> > >> What do you think about adding NOT EXIST functionality to PREPARE?
> > >
> > > Not very much. If you're not in in control of the prepared statements, you
> > > can't be sure it's not an entirely different statement. So NOT EXISTS
> > > doesn't really buy you anything, you'd still need to compare the
> > > statement somehow.
> >
> > Strongly disagree! A typical use case of this feature would be in
> > connection pooler scenarios where you *are* in control of the
> > statement but it's a race to see who creates it first. This feature
> > should be immediately be incorporated by the JDBC driver so that we'd
> > no longer have to disable server side prepared statements when using
> > pgbounder (for example).
>
> Uh. JDBC precisely is a scenario where that's *NOT* applicable? You're
> not in control of the precise prepared statement names it generates, so
> you have no guarantee that one prepared statement identified by its name
> means the same in another connection.

Clearly, you'd need to be able to control the prepared statement name to
use such a feature.

Given that we're talking about what sounds like a new feature in the
JDBC driver, I don't see why you wouldn't also make that a requirement
of the feature..? Or have the JDBC driver calculate a unique ID for
each statement using a good hash, perhaps?

Note: I don't pretend to have any clue as to the internals of the JDBC
driver, but it hardly seems far-fetched to have this be supported in a
way that works.

Thanks!

Stephen