On Wed, 30 Oct 2024 at 19:04, Jesper Pedersen <jesper.peder...@comcast.net> wrote: > Having LSN would be nice, but to break all existing implementations, no. > Having to specify with startup parameters how a core message format > looks like sounds like a bad idea to me,
It would really help if you would explain why you think it's a bad idea to use a startup parameter for that, instead of simply stating that you think it needs a major protocol version bump. The point of enabling it through a startup parameter (aka protocol option) is exactly so it will not break any existing implementations. If clients request the protocol option (which as the name suggests is optional), then they are expected to be able to parse it. If they don't, then they will get the old message format. So no existing implementation will be broken. If some middleware/proxy gets a request for a startup option it does not support it can advertise that to the client using the NegotiateProtocolVersion message. Allowing the client to continue in a mode where the option is not enabled. So, not bumping the major protocol version and enabling this feature through a protocol option actually causes less breakage in practice. Also regarding the wishlist. I think it's much more likely for any of those to happen in a minor version bump and/or protocol option than it is that we'll bump the major protocol version. P.S. Like I said in another email on this thread: I think for this specific case I'd also prefer a separate new message, because that makes it easier to filter that message out when received by PgBouncer. But I'd still like to understand your viewpoint better on this, because adding fields to existing message types is definitely one of the types of changes that I personally think would be fine for some protocol changes.
