On Sat, Dec 25, 2004 at 07:05:07PM -0500, Kris Jurka wrote:
I don't see this as all that helpful for a client interface that does the
preparation itself. Possibly it could be used for libpq, but you
mentioned DBI which should already know what it has or has not prepared. The idea of adding a network round trip to detect a prepared statement
seems like a performance loss, not a gain. If this is just to avoid
repreparing the same statement then perhaps something like PREPARE OR
REPLACE would be more useful.
You're right, in the case of standalone Perl or Apache::DBI. However, if DBD::Pg happens to grab an already-open connection that doesn't have a one-to-one correspondence with a $dbh (e.g. from a Postgres connection pool, or from an external pooling server like DBBalancer), the state of the connection (with respect to past PREPAREs) isn't known.
In the case of an external-to-Perl connection pool, We'd make one round trip to the server to fill in DBD::Pg's list of prepared statements, at DBD::Pg::db::connect() - not at every prepare (which, as you said, would be a net loss).
(DBD:::Pg, in fact, ships with server-side prepares totally turned off. I have some code that fixes that for the SELECT and DELETE cases, but it, like the rest of this stuff, isn't really release-quality yet.)
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly