Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers