Re: NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Merlin,
>
> * Merlin Moncure (mmoncure@gmail.com) wrote:
>> No one is arguing that that you should send it any every time (at
>> least -- I hope not).
>
> I'm not sure I follow how you can avoid that though?
>
> pgbouncer in transaction pooling mode may let a particular connection
> die off and then, when you issue a new request, create a new one- which
> won't have any prepared queries in it, even though you never lost your
> connection to pgbouncer.
>
> That's why I was saying you'd have to send it at the start of every
> transaction, which does add to network load and requires parsing, etc.
> Would be nice to avoid that, if possible, but I'm not quite sure how.
>
> One thought might be to have the server somehow have a pre-canned set of
> queries already set up and ready for you to use when you connect,
> without any need to explicitly prepare them, etc.
>
> 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. :/

merlin



merlin