> 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@xxxxxxxxxxxxxxxxx> 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 sameconnection is being used at the same time from different parts of theapplication. 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 theabove scenarios. If the connection is reused but the code is fresh (being PHP andliving in a webpage lifecycle) the hash in the code will be empty butthe statements are in fact still there. Or if parts of the application issue their own PREPAREs without goingthrough the central mechanism with the hash (granted, this is aninternal issue of code discipline). Still, I don't wanna have to query pg_prepared_statements for everyquery I make. I feed that a hybrid approach might be best. Early inthe lifecycle of every script I could load pg_prepared_statements inthe code hashtable, then the mechanism could proceed normally,checking only against the hashtable. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-general
