Re: NOT EXIST for PREPARE

On Friday, May 6, 2016, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure <mmoncure(at)gmail(dot)com
> <javascript:;>> wrote:
> > On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure <mmoncure(at)gmail(dot)com
> <javascript:;>> wrote:
> >> On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfrost(at)snowman(dot)net
> <javascript:;>> wrote:
> >>> Just a thought. I do still like the general idea of INE support for
> >>> PREPARE, but perhaps there's a better option.
> >>
> >> Admittedly, you make some pretty good points here. I guess one
> >> strategy would be to move them all to a function that sets an advisory
> >> lock to signal they've been prepared. That's pretty safe even in
> >> multi-threaded scenarios since only one thread can send queries to the
> >> backend at a time. Advisory locks are pretty arcane though. Still,
> >> I'm coming round to your (and Andres's) point of view. :/
> >
> > I signed up to review this patch as I thought I'd be a pretty fair
> > arbitrator of the "is this or is this not actually useful?" debate. I
> > was initially pretty enthusiastic about this patch but after reviewing
> > the various objections I've gradually come around to the opinion that
> > the author really ought to demonstrate specific use cases where the
> > new syntax actually helps with pain points. On the one hand, IF NOT
> > EXISTS is seems pretty harmless but on the other we try not to accept
> > patches for SQL level features that will not (or should not) ever by
> > used.
>
> Yeah. I would assume that if you have a large number of statements
> that you want to potentially prepare, it would be smarter to first
> issue "SELECT name FROM pg_prepared_statements", and then prepare any
> you need that aren't already there. Blindly pre-preparing everything
> doesn't seem like it will be good for performance, and if you do want
> to do it for some reason, you can always ignore the error on the
> client side. So I'm not really seeing the use case for this.
>
>
So the OP only expressed curiosity and the linked SO post is also curiosity
expressed by a user who admittedly had an error and IMO was better off
seeing the error message than having a blindly replaced prepared statement.

I don't know if these things should be held open until the cf properly
commences but I'd say at this point it should be marked rejected as feature
not meeting a described need. Anyone following and wanting to propose a
concrete need can resurrect the idea.

As an aside; most (all?) of our INEs apply to persistent schema objects.
Extending that to session objects is a conceptual leap.

David J.