On Friday, May 6, 2016, Robert Haas <robertmh...@gmail.com> wrote:

> On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure <mmonc...@gmail.com
> <javascript:;>> wrote:
> > On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure <mmonc...@gmail.com
> <javascript:;>> wrote:
> >> On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfr...@snowman.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.

Reply via email to