public inbox for [email protected]
help / color / mirror / Atom feedRe: Proposal to allow setting cursor options on Portals
2+ messages / 2 participants
[nested] [flat]
* Re: Proposal to allow setting cursor options on Portals
@ 2026-01-08 09:45 Jelte Fennema-Nio <[email protected]>
2026-01-08 19:01 ` Re: Proposal to allow setting cursor options on Portals Robert Haas <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Jelte Fennema-Nio @ 2026-01-08 09:45 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Dave Cramer <[email protected]>; PostgreSQL Hackers <[email protected]>; Heikki Linnakangas <[email protected]>
On Thu, 8 Jan 2026 at 01:39, Jacob Champion
<[email protected]> 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 protected]
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Proposal to allow setting cursor options on Portals
2026-01-08 09:45 Re: Proposal to allow setting cursor options on Portals Jelte Fennema-Nio <[email protected]>
@ 2026-01-08 19:01 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Robert Haas @ 2026-01-08 19:01 UTC (permalink / raw)
To: Jelte Fennema-Nio <[email protected]>; +Cc: Jacob Champion <[email protected]>; Dave Cramer <[email protected]>; PostgreSQL Hackers <[email protected]>; Heikki Linnakangas <[email protected]>
On Thu, Jan 8, 2026 at 4:46 AM Jelte Fennema-Nio <[email protected]> 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-01-08 19:01 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-08 09:45 Re: Proposal to allow setting cursor options on Portals Jelte Fennema-Nio <[email protected]>
2026-01-08 19:01 ` Robert Haas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox