On Wed, Mar 11, 2026 at 2:39 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2026-03-11 21:22:14 +0000, nik@postgres.ai 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 <rhaas@postgresql.org>
> 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 <drowley@postgresql.org>
> 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
