MIME-Version: 1.0
References: 
 <CAM527d_y5MOGRgqFhgDOD3DOCyB8N0ExDBnu-xPjMqCmdm4+=g@mail.gmail.com>
 <mgrurx4o6icyqhi4oniflwltrvoetfs62pmhhn3bnj24jao46a@q5pe2oqdjqva>
In-Reply-To: <mgrurx4o6icyqhi4oniflwltrvoetfs62pmhhn3bnj24jao46a@q5pe2oqdjqva>
From: Nikolay Samokhvalov <nik@postgres.ai>
Date: Wed, 11 Mar 2026 14:58:02 -0700
Message-ID: 
 <CAM527d-i0SrQpboy08MQ8bABPLJGPULm3itTBx6jS9M6XVXrsA@mail.gmail.com>
Subject: 
 =?UTF-8?Q?Re=3A_=5BPATCH_v1=5D_command=5Ftag=5Fformat_=E2=80=94_protocol=2Dlevel?=
	=?UTF-8?Q?_command_tag_negotiation_via_=5Fpq=5F?=
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, wolakk@gmail.com,
	amborodin86@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAM527d-i0SrQpboy08MQ8bABPLJGPULm3itTBx6jS9M6XVXrsA%40mail.gmail.com>
Precedence: bulk

On Wed, Mar 11, 2026 at 2:39=E2=80=AFPM 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, sen=
d
>     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. W=
e'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 =E2=80=93 that's not super convenient. If pg_dump would use th=
is
(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