Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 15:48, Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> Put another way: for a middlebox on the connection (which may be
> passively observing, but also maybe actively adding new messages to
> the stream), what is guaranteed to remain the same in the protocol
> across a minor version bump? Hopefully the answer isn't "nothing"?

I think primarily we do a minor version bump because a major version
bump would cause existing Postgres servers to throw an error for the
connection attempt (and we don't want that). While for a minor version
bump they will instead send a NegotiateProtocolVersion message.

In practical terms I think that means for a minor version bump the
format of the StartupMessage cannot be changed. Changing anything else
is fair game for a minor protocol version bump. I think we probably
would not want to change the format of ErrorResponse and
NoticeResponse, since those can be sent by the server before the
NegotiateProtocolVersion message. But I don't even think that is
strictly necessary, as long as clients would be able to parse both the
old and new versions.

Note that this definition arises from code and behaviour introduced in
ae65f6066dc3 in 2017. And PQprotocolVersion was introduced in
efc3a25bb0 in 2003. So anyone starting to use the PQprotocolVersion
function in between 2003 and 2017 had no way of knowing that there
would ever be a thing called a "minor" version, in which anything
about the protocol could be changed except for the StartupMessage.