> 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 <[EMAIL PROTECTED]> 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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
