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.
