The basic idea would be to combine the power afforded by explicit connections and the performance benefits of pooling.

Today it's not possible to setup a connection with custom commands for pooled connections, you don't know when they're being recycled and you don't know if you got a fresh connection handed out. In practice this means you always have to send any connection setup you need to do with each query you make, in the event the connection wasn't setup yet.

Setup would be things like, temp tables, planner options or other runtime configuration postgres exposes.

The suggestion here would be to introduce a delegate hook for user sql, the returned sql will be queued onto the connection to be sent in the same roundtrip as the rest of the sql, this feature should work with or without pooling turned on.

We could also entertain the possibility of going further and introducing an enum with cases like PhysicalOpen,PhysicalClose,Open,Close
This would allow users to setup and tear down important details like the current role for RLS (row level security) as a cross cutting concern.

As a concrete use case today I have done some simple wrk load testing, always sending DDL like CREATE TEMP TABLE IF NOT EXISTS ... means taking a hit of about 20% in TPS for my particular query.

Query is something like:

• create temp table
• fill it with 12 records
• select these rows joined to their data table
• select these rows joined to another table

Not small not large either, so the hit is substantial even when PG needs to do some work to compute the results.