On Friday, May 6, 2016, Robert Haas <
robertmhaas@gmail.com> wrote:
On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfrost@snowman.net> 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.
