On Wed, 30 Oct 2024 at 07:49, Tatsuo Ishii <is...@postgresql.org> wrote: > > I think one would have to define that somehow. If it's useful, the > > additional fields of both extensions could be appended, in some > > defined order. But this is an interesting question to think about. > > I think this kind of extension, which adds new filed to an existing > message type, should be implemented as v4 protocol.
Could you explain why you think a major version bump is needed? In what situation do you care about this. Because for my usecases (client implementations & pgbouncer) I don't think that would be necessary. If a client doesn't send the _pq_.wait_for_lsn protocol parameter, it will never receive this new version. I don't really see a problem with having two protocol parameters change the same message. Yes, you have to define what the result of their combination is, but that seems trivial to do for additions of fields. You either define the first protocol parameter that was added to the spec, to add its field before the second. Or you could do it based on something non-time-dependent, like the alphabetic order of the protocol parameter, or the alphabetic order of the fields that they add. The main guarantees I'd like to uphold are listed here: https://www.postgresql.org/message-id/cageczqr5pmud4q8atyz0gooj1xnh33g7g-mlxfml1_vrhbz...@mail.gmail.com
