Robert Haas <robertmhaas@gmail.com> writes:
> Here's my proposal:
> - If the server receives a StartupMessage for v3.x where x > the
> version it knows, instead of just slamming the connection shut, it
> responds by sending some new message (let's say,
> NegotiateProtocolVersion) specifying the highest protocol version it
> supports.
> - The client may then continue by sending a new StartupMessage with a
> version with a version number that is within range.
How about a slightly simpler design: we specify that all 3.x protocol
versions shall be mutually compatible so long as each side knows not
to send something that the other side doesn't understand. The field
in the StartupMessage is understood to be the max protocol version the
client knows how to cope with. If the client sends something > 3.0,
then the server responds with a ServerProtocolVersion message containing
the max protocol version it understands. Now both sides know what the
other side can do and should be able to adapt their behavior accordingly.
(If the client doesn't get a ServerProtocolVersion message, it should
assume server protocol 3.0.)
In order to make the world safe for this, we'd have to adjust existing
releases to not complain about 3.x for x > 0, and the sooner we do that
the better chance of clients being able to make use of this within a
reasonable timeframe.
It's possible that we should do something that's not based on just a
linear protocol version number, but instead involves some kind of
bitmask of capabilities, say. So the ServerProtocolVersion message
maybe needs to be a bit more complicated, and if the client does get
one back, maybe it should forward a ClientProtocolVersion message with
its own bitmask. But these things could be designed in detail later.
regards, tom lane
