Re: Proposal to allow setting cursor options on Portals

On Wed, 10 Dec 2025 at 12:41, Jacob Champion <
jacob.champion@enterprisedb.com> wrote:

> On Mon, Dec 8, 2025 at 1:43 PM Jelte Fennema-Nio <postgres@jeltef.nl>
> wrote:
> > 1. We still have fairly limited experience with protocol options, so
> > afaik not everyone agrees what we should use a version bump for vs a
> > protocol extension.
>
> I think it'd be helpful for proposals to describe why a minor version
> bump was chosen over a protocol extension parameter (or vice versa),
> so that we can begin to develop some consensus.
>

 The reasons I chose a protocol bump include:
1/ I actually think this was an oversight from the original spec. I am not
adding any new features to the server, only implementing existing options
on a portal/cursor that should have been in the original protocol
2/ I'm hoping and expect that there will be other additions to the protocol
for 3.3 such as returning the LSN after commit, binary return values per
session

>
> To me, the conversation on the wire for this feature seems perfect for
> an extension parameter: "Hello server, do you support this optional
> thing in this one message type? If not, let me know." Especially since
> the optional thing is itself an extensible bitmap! With the
> minor-version strategy, if we added new bits in 3.6, clients who just
> wanted those new bits would then have to implement support for every
> feature in versions 3.4, 3.5, and 3.6 just to improve that one use
> case, and that incentive mismatch leads to more ossification IMO.
>
> = Soapbox Follows =
>
> I've talked about it face-to-face with people, but to go on the public
> record: I don't think this is a wise use of a minor version upgrade
> strategy. I prefer protocol architectures that introduce separate
> extensions first, then periodically bundle the critical and
> highly-used extensions into a new minor version once they're sure that
> _everyone_ should support those things.
>
> I know that 3.2 didn't do that. My view of 3.2 is that it was a big
> compromise to get some things unstuck, so overall I'm glad we have it
> -- but now that we have it, I'd rather that 3.next be more
> intentional. Plus I think it's unwise to introduce a 3.3 before we're
> confident that 3.2 can be widely deployed, and I'm trying to put
> effort into the latter for 19, so that I'm not just sitting here
> gatekeeping.
>
> pgjdbc already supports 3.2. Unfortunately we have no idea how many people
actually use it.


> IETF has a bunch of related case studies [1,2,3] that might be useful
> reading, even if we decide that their experience differs heavily from
> ours.
>

I read the articles which sadly gloss over protocol negotiation issues.

Dave

>
>
>