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, though, there may not
be any guarantee that the same client-side connection object (in your
example, the proxy object) will always be associated with the same
underlying connection (the open socket to Postgres).
Multiple machines connecting through a single connection pooling server need
some way to communicate the state of a particular connection between
themselves ("state", in this case, being the list of prepared queries).
This information could be tracked by the connection pool, it could be
tracked by the clients and shared through some back channel, or it could
just be exposed via SQL (since Postgres already has it in a convenient
format).
The patch provides a way to inspect the list of prepared queries on a
connection, via SQL. It'd be up to the client to avoid this round-trip when
it isn't necessary (e.g. the single-server or single-process cases you've
mentioned, where keeping and sharing the list of prepared statements is
cheap).
At a bare minimum, it'd at least be convenient for humans to be able to
connect to a pool and look at what's been prepared. There was no way to do
this before.
- Dave
