On Mon, Dec 27, 2004 at 01:03:08PM -0500, Kris Jurka wrote:
has not prepared. So I don't see why, simply because it's in a pool, that
it forgets what's been prepared.
The connection (the open socket to Postgres) doesn't forget anything. If
you have multiple machines sharing a connection pool,
On Sat, 25 Dec 2004, David Brown wrote:
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
On Wed, 22 Dec 2004, David Brown wrote:
This would allow an application inheriting a pooled connection to know
the queries prepared in the current session.
I don't see this as all that helpful for a client interface that does the
preparation itself. Possibly it could be used for
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
Hi:
Attached is a loadable module (and a small backend patch) that allows a
client to list the available query plans (created with PREPARE, or with a
'parse' protocol message) on a particular connection.
This work was done in response to an item in the TODO:
* Allow pooled connections to list
David Brown [EMAIL PROTECTED] writes:
Attached is a loadable module (and a small backend patch) that allows a
client to list the available query plans (created with PREPARE, or with a
'parse' protocol message) on a particular connection.
* Extended PostgreSQL's SQL grammar to capture the
