public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nikolay Samokhvalov <[email protected]>
To: Andres Freund <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: [PATCH v1] command_tag_format — protocol-level command tag negotiation via _pq_
Date: Wed, 11 Mar 2026 14:58:02 -0700
Message-ID: <CAM527d-i0SrQpboy08MQ8bABPLJGPULm3itTBx6jS9M6XVXrsA@mail.gmail.com> (raw)
In-Reply-To: <mgrurx4o6icyqhi4oniflwltrvoetfs62pmhhn3bnj24jao46a@q5pe2oqdjqva>
References: <CAM527d_y5MOGRgqFhgDOD3DOCyB8N0ExDBnu-xPjMqCmdm4+=g@mail.gmail.com>
<mgrurx4o6icyqhi4oniflwltrvoetfs62pmhhn3bnj24jao46a@q5pe2oqdjqva>
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
view thread (3+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Re: [PATCH v1] command_tag_format — protocol-level command tag negotiation via _pq_
In-Reply-To: <CAM527d-i0SrQpboy08MQ8bABPLJGPULm3itTBx6jS9M6XVXrsA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox