MIME-Version: 1.0
References: <CADK3HHKe1PA1U6aB5-7tWBQ0yZGgNvY7H=ECDD9955Pas_zx_Q@mail.gmail.com>
 <CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
 <CAOYmi+nVQRpSs3vd_v9L8ytO9wnL2ndnzGwU31aDGorVFxrAYA@mail.gmail.com>
 <CAGECzQSZ43JMjA8QEJoF9DCdTO0GQeR2qyhouQciSG2ik40Yhg@mail.gmail.com>
 <CAOYmi+m20jS8zZ2qFpSnvhaqGDX+vtgCsqcu9VhokyLqF8kFag@mail.gmail.com>
 <CADK3HH+DPY_x_H=e0c_AVWoUP9E+YXdyJDVvmzYEYxZXT87Agw@mail.gmail.com>
 <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com>
 <CADK3HHKDrnRAoAcUv1ucLB0o_ZUcJRwm+jonNPNUHoDtcA9Crw@mail.gmail.com>
 <CAGECzQQriv-h_h8Ygxh_RfnLt2G4P9nWrpgMi9YL2bmcOLbUEA@mail.gmail.com>
 <CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@mail.gmail.com>
 <CADK3HH+o9dTYsXpCk7-Z0JW-QB2TV7=e97O8B-XDOGQb14AfSQ@mail.gmail.com>
 <CAOYmi+kkTbuwGa9X=XomNivAw9P4hN3M1U7QXiP7Jw+nrQXtNQ@mail.gmail.com>
 <CAGECzQSfCPXdOpUKfdkPA9iZhGyRjZAad-CXbhApZ2CnjgG2kw@mail.gmail.com>
 <CAOYmi+=qE1khrtTD7oQVPJQTHoXffQQ0DPHOx870r7801zhw9g@mail.gmail.com> <CAGECzQTKQvusp7_-1VOCz8uy-rtBaJTu5HOsB6jr4VBri9S1oA@mail.gmail.com>
In-Reply-To: <CAGECzQTKQvusp7_-1VOCz8uy-rtBaJTu5HOsB6jr4VBri9S1oA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 8 Jan 2026 14:01:38 -0500
Message-ID: <CA+TgmoZyh3gGazhu3kvz4LNSyh6ifUx-sSCyiAoJ+3EnyBSVZg@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Dave Cramer <davecramer@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoZyh3gGazhu3kvz4LNSyh6ifUx-sSCyiAoJ%2B3EnyBSVZg%40mail.gmail.com>
Precedence: bulk

On Thu, Jan 8, 2026 at 4:46=E2=80=AFAM Jelte Fennema-Nio <postgres@jeltef.n=
l> wrote:
> tl;dr I give up, let's do protocol extensions for everything. I've
> updated my GoAway patch do so[1].
>
> I don't think I can convince you that slightly more forceful push
> forward that I'm suggesting is worth the gained simplicity (both for
> us, users and client authors). And I'm starting to get pretty sick of
> discussing the same points over and over again, without making any
> progress. So instead of continuing to do so, I'll just agree to
> disagree with you.

That sounds like the right approach to me. Note that I have also
previously expressed my disagreement with the idea of bumping the
protocol version regularly. I'm not entirely comfortable with the idea
of using protocol extensions for everything, because I really imagined
that they would be used for larger features that made a cluster of
related changes rather than solitary changes, and that there wouldn't
be many of them. If we have lots of them and use them for solitary
changes like GoAway, we will eventually end up with a very long list
of protocol extensions. I agree with you that this is not great. On
the other hand, I also do not think the alternative of bumping the
protocol version every year is viable. And even if I did, working in
this community means that you sometimes have to defer to a consensus
with which you do not personally agree in the interest of getting
stuff done. I find that when 2 or 3 people all disagree with the same
decision that I've made, it is usually a sign that I am wrong,
regardless of how sure I am that I am not wrong.

> If in 5 years, when we have 15 protocol extensions with completely
> distinct support across clients and proxies instead, and no-one knows
> what features they can rely on in practice. While we could have had 5
> new protocol versions. I'll just think (and probably tell you) "I told
> you so". But you might just be right, and that won't happen, or even
> if it does it will somehow be trivial to compare all the compatibility
> matrices.

IMHO, one thing upon which this greatly depends is the degree to which
all the changes are interdependent. If we end up with an extension for
a GoAway message, an extension for column encryption, and an extension
for trace IDs, I don't see why the compatibility matrix should be a
huge issue. Like, yes, some 3rd-party implementations will support all
of those and some will support only some of them, but that's sort of
the point. Our own code should work with any combination -- I hope --
because the code should live in pretty separate places. If we end up
with extensions for column encryption, column use-of-binary format,
and column encoding, well then it's probably going to be quite a mess
to keep our stuff working with all combinations. In that case, we need
to either bump the version and mandate that you have to support all of
them, or have extremely good testing frameworks, or maybe decide not
to add all those features.

--=20
Robert Haas
EDB: http://www.enterprisedb.com