Hi,
I know that this will probably get a staunch "No" as an answer, but...
I'm still going to ask: Would it be possible to backport 28b5726 to
the PG16 branch? Even though it's clearly a new feature?
I'm working on named prepared statement support in PgBouncer:
https://github.com/pgbouncer/pgbouncer/pull/845 That PR is pretty
close to mergable (IMO) and my intention is to release a PgBouncer
version with prepared statement support within a few months.
28b5726 allows sending Close messages from libpq, as opposed to
sending DEALLOCATE queries to deallocate prepared statements. Without
support for Close messages, libpq based clients won't be able to
deallocate prepared statements on PgBouncer, because PgBouncer does
not parse SQL queries and only looks at protocol level messages (i.e.
Close messages for deallocation).
Personally I think backpatching 28b5726 has a really low risk of
breaking anything. And since PgBouncer is used a lot in the Postgres
ecosystem, especially with libpq based clients, IMO it might be worth
deviating from the rule of not backporting features after a STABLE
branch has been cut. Otherwise all libpq based clients will have only
limited support for prepared statements with PgBouncer until PG17 is
released.
Jelte