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.
