On Wed, Mar 11, 2026 at 2:39 PM Andres Freund <[email protected]> wrote: > > Hi, > > On 2026-03-11 21:22:14 +0000, [email protected] wrote: > > PostgreSQL has had a protocol feature negotiation framework since > > 7.4 (the _pq_ namespace in startup parameters) -- over 20 years -- > > but it's never been used in practice. > > Wasn't that added in > > commit ae65f6066dc > Author: Robert Haas <[email protected]> > Date: 2017-11-21 13:56:24 -0500 > > Provide for forward compatibility with future minor protocol versions. > > Previously, any attempt to request a 3.x protocol version other than > 3.0 would lead to a hard connection failure, which made the minor > protocol version really no different from the major protocol version > and precluded gentle protocol version breaks. Instead, when the > client requests a 3.x protocol version where x is greater than 0, send > the new NegotiateProtocolVersion message to convey that we support > only 3.0. This makes it possible to introduce new minor protocol > versions without requiring a connection retry when the server is > older. > > PG 14 / 2017 is quite a while after 7.4...
Right, I confused it, _pq_ namespace reserved long, long ago, but the actual NegotiateProtocolVersion mechanism is from 2017 indeed. My bad. > > legacy - INSERT 0 N (default, fully backward compatible) > > verbose - INSERT tablename N > > fqn - INSERT schema.tablename N > > Pretty doubtful this survives the complexity / gain tradeoff. > > > > Separately, doing extra work during command handling isn't free either. We've > spent a decent amount of effort in the past lowering it, see e.g. > > commit ac998020802 > Author: David Rowley <[email protected]> > Date: 2022-12-16 10:31:25 +1300 > > Speed up creation of command completion tags > > > I'm loathe to add work to every statement. On performance: the extra work (relname lookup) only runs when a client explicitly opts in. The default legacy path adds just one integer comparison, so almost nothing. The two new QueryCompletion pointers are initialized to NULL and never touched in legacy/default mode. That said, this was meant purely as a discussion starter -- is pq the right mechanism for per-connection feature negotiation like this, or would something else be preferred? For example, when restoring from a large dump, we see a lot of "INSERT 0 N" emitted – that's not super convenient. If pg_dump would use this (and I think, in this case the overhead would be really acceptable), then we would see something like "INSERT tblname N", understanding what table already received data. Nik
