On Thu, 8 Jan 2026 at 14:22, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: > > 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. > > I kind of doubt that there will ever be many of them, but if we start > to feel like there's a lot, we could invent abbreviations: single > feature names that clients can ask for that are defined to represent > a particular set of older features. But I'd argue that those sets > should be groups of related functions, not "whatever random stuff > exists as of Postgres 27". I think it'll be highly useful for clients > to declare which features they want, rather than leave people > wondering exactly which features this client intends to support. > > regards, tom lane >
For the particular case of adding the ability to create holdable cursors at the protocol level which is what my patch is concerned with I don't think it's even necessary to bump the protocol or create a protocol extension. The change in the message is backward compatible and clients only need to know that after version 18 they can use the message to create a holdable cursor. I would argue that this patch is just rectifying an oversight in the original protocol. Dave
