Jacob Champion <jacob.champion@enterprisedb.com> writes:
> You're saying "well hopefully clients don't actually have to support
> all of them," but I don't think you gave a reason why that would be
> okay for a production implementation. Is there an unstated assumption
> here, that we'll eventually drop support for 3.0 at some point
> relatively soon? (And then 3.2, and then...) If so, I'd prefer to
> focus the conversation on that assumption. Because that seems like a
> complete nonstarter to me, personally.
After we introduced protocol version 3.0, it took us 18 years to drop
support for version 2 (2003..2021). We introduced 3.2 in 2025, so on
the same schedule we won't drop 3.0 support before 2043. If anyone's
thinking that it can happen significantly faster this time around,
I'm here to disabuse you of that notion. Considering how much larger
the Postgres ecosystem is now than it was in 2003, it will probably
take *longer* for everything to be sufficiently on-board for another
hard break.
I'm pretty bemused by this entire discussion. We have a perfectly
good design for handling new protocol features without any hard
protocol break, so I don't understand why people are insisting on
doing things incompatibly when they could be doing them compatibly.
I quote from Robert's commit ae65f6066 (the same one that invented
NegotiateProtocolVersion):
In addition, if the startup packet includes name/value pairs where
the name starts with "_pq_.", assume that those are protocol options,
not GUCs. Include those we don't support (i.e. all of them, at
present) in the NegotiateProtocolVersion message so that the client
knows they were not understood. This makes it possible for the
client to request previously-unsupported features without bumping
the protocol version at all; the client can tell from the server's
response whether the option was understood.
I think that the right way forward is that the protocol version
stays at 3.2 for several decades more, and we implement requests for
individual protocol-level features through the "_pq_." mechanism.
I would not have any use for 3.2 as such at all, except that
asking for that is needed to ensure that the server knows about
NegotiateProtocolVersion.
regards, tom lane
