Robert Haas <robertmhaas@gmail.com> 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.
