Re: Proposal to allow setting cursor options on Portals - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Proposal to allow setting cursor options on Portals
Date
Msg-id CAOYmi+=qE1khrtTD7oQVPJQTHoXffQQ0DPHOx870r7801zhw9g@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to allow setting cursor options on Portals  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: Proposal to allow setting cursor options on Portals
Re: Proposal to allow setting cursor options on Portals
Re: Proposal to allow setting cursor options on Portals
List pgsql-hackers
On Wed, Jan 7, 2026 at 6:48 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I had a quick discord chat with Dave. And we don't disagree much with
> each other: We both would like to use a version bump for these kinds
> of very simple to implement features.

I asked because I'm worried that the strongest technical argument for
this strategy is "it's simpler (for us)", outweighing all
consideration of downstream consequences. I'm not really on board with
that.

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.

> Having a single version is only 1 option,

Seems like clients must support 3.0 up to 3.N in practice, and test
all of those. If you want a feature in 3.6 and the server says it only
supports 3.4, you're speaking 3.4 now. That's still N options.

You're saying "well hopefully clients don't actually have to support
all of them," but I don't think you gave a reason why that would be
okay for a production implementation. Is there an unstated assumption
here, that we'll eventually drop support for 3.0 at some point
relatively soon? (And then 3.2, and then...) If so, I'd prefer to
focus the conversation on that assumption. Because that seems like a
complete nonstarter to me, personally.

--Jacob



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: improve performance of pg_dump with many sequences
Next
From: Chao Li
Date:
Subject: Re: Refactor replication origin state reset helpers