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.
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings