Re: NOT EXIST for PREPARE

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>
Subject: Re: NOT EXIST for PREPARE
Date: 2016-03-22 14:37:15
Message-ID: CAHyXU0wm+rPgTBhaZFG0FtgDOptxqV8WMtyrys7-tyFvGsDx6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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).

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2016-03-22 14:40:07 Re: improving GROUP BY estimation
Previous Message Petr Jediný 2016-03-22 14:36:44 Re: BRIN is missing in multicolumn indexes documentation