Peter Eisentraut <peter_e@gmx.net> writes:
> On sön, 2011-10-09 at 11:51 -0400, Tom Lane wrote:
>> The problem with something like a protocol bump is that the coding
>> required to make it happen (in the backend and libpq, that is) is only
>> a small part of the total distributed cost.
> Why do we have major and minor protocol version numbers, which are
> supposed to allow incremental addition of features to the protocol?
Well, that's a good question. I seem to recall that the last time it
was discussed, questions were raised about whether a minor-number
version bump would really work as desired. In particular, if the client
connects asking for 3.1 and the server doesn't know anything later than
3.0, you end up having to do another connection cycle, which is rather
inefficient and has got unpleasant failure cases too. This could be
avoided if there were a way to have the server allow the connection but
only at 3.0 level, but (1) there is no way to report that in 3.0
protocol, and (2) requiring clients to support 3.0 as well as 3.1 could
be burdensome.
Basically, it's uncharted territory, because we've never actually done
it before. It wouldn't be a bad idea to put "make sure upgrading to a
4.1 protocol version will actually work smoothly" into our list of goals
for protocol 4.0 ...
regards, tom lane