Hi Kris:
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 add
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, t
Hi Tom:
On Fri, Dec 24, 2004 at 11:00:57AM -0500, Tom Lane wrote:
* Extended PostgreSQL's SQL grammar to capture the original SQL query
string for PREPARE statements.
This seems much the ugliest and most invasive part of the patch. I'd
suggest doing something similar to what pg_proc.c is doin
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 a
