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.
So, to the OP, if you could reiterate some specific cases where you
think this would be useful, that will help move the review forward.
(if not, it makes it more likely you'll get marked, "returned with
feedback" -- FYI, and thanks. Note, I'm not the final word here but I
think I speak for the prevailing opinion in this regard.
merlin