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