On Wed, 10 Dec 2025 at 12:41, Jacob Champion < [email protected]> wrote:
> On Mon, Dec 8, 2025 at 1:43 PM Jelte Fennema-Nio <[email protected]> > 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 > > >
