* Andres Freund (and...@anarazel.de) wrote: > On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: > > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund <and...@anarazel.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
signature.asc
Description: Digital signature
