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

From Merlin Moncure
Subject Re: NOT EXIST for PREPARE
Date
Msg-id CAHyXU0wsZ4_uosLOPHvOvx5KOFE+wOewmEw8SV4W4=wkecga2A@mail.gmail.com
Whole thread Raw
In response to Re: NOT EXIST for PREPARE  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On Wed, Mar 23, 2016 at 8:21 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> I'm not understanding the objection at all.  You have N client
> sessions connecting to the database that all utilize the same named
> prepared statement.  A typical pattern is for the application to
> prepare them all upon startup, but currently each PREPARE needs to be
> wrapped with an exception handler in case someone else prepared it
> first.  Having an IF NOT EXISTS decoration simplifies this.  This can
> happen both inside and outside of connection pooling scenarios.

I'm walking that back a bit -- this is only interesting in pooler
scenarios, especially pgbouncer where you have no way of knowing if
the statement is created or not.  Of course, you can always re-prepare
them following a discard but that's quite pessimal in many cases.
Still, I've often wanted this exact feature.

merlin



pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: NOT EXIST for PREPARE
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator