Subject: Re: Proposal to allow setting cursor options on Portals

From: Jelte Fennema-Nio <[email-masked]>
Date: Thu, 8 Jan 2026 10:45:54 +0100

On Thu, 8 Jan 2026 at 01:39, Jacob Champion
<[email-masked]> wrote:
> Dave seems not to be particularly worried about our compatibility with
> third parties. You seem to be hoping to _force_ clients to update,
> even if they disagree with you that they need the new features. I
> think I'm on record as saying these are both bad starting points when
> making changes to a widely implemented protocol. (If not, now I am.)
> That combination will burn hard-earned trust and goodwill.

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.

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.

[1]: https://www.postgresql.org/message-id/flat/[email-masked]

---

From: Robert Haas <[email-masked]>
Date: Thu, 8 Jan 2026 14:01:38 -0500

> progress. So instead of continuing to do so, I'll just agree to

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 it does it will somehow be trivial to compare all the compatibility

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.

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