On Wed, 30 Oct 2024 at 07:49, Tatsuo Ishii <ishii@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_Vrhbzs6Q@mail.gmail.com
