> Merlin Moncure escribió:
>> pg_prepared_statements (on recent versions of postgresql)
Thank you, that's one of the things I wanted to know.
On Thu, Nov 20, 2008 at 15:30, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Merlin Moncure escribió:
>> also, watch out for race conditions.
>
> What race conditions? Prepared statements are per-connection.
I guess he means if connections are persistent, or if the same
connection is being used at the same time from different parts of the
application. Which brings us to the next point:
> Perhaps the application could keep a hash of statements prepared so far,
> to avoid having to query pg_prepared_statements all the time.
That's how I dealt with it so far, purely in the code. But see the
above scenarios.
If the connection is reused but the code is fresh (being PHP and
living in a webpage lifecycle) the hash in the code will be empty but
the statements are in fact still there.
Or if parts of the application issue their own PREPAREs without going
through the central mechanism with the hash (granted, this is an
internal issue of code discipline).
Still, I don't wanna have to query pg_prepared_statements for every
query I make. I feed that a hybrid approach might be best. Early in
the lifecycle of every script I could load pg_prepared_statements in
the code hashtable, then the mechanism could proceed normally,
checking only against the hashtable.