Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility

On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer <fweimer(at)bfk(dot)de> wrote:
> * Robert Haas:
>>> In this particular case, I knew that the change was coming and could
>>> push updated Java and Perl client libraries well before the server-side
>>> change hit our internal repository, but I really don't want to have to
>>> pay attention to such details.
>>
>> But if we *don't* turn this on by default, then chances are very good
>> that it will get much less use.  That doesn't seem good either.  If
>> it's important enough to do it at all, then IMHO it's important enough
>> for it to be turned on by default.  We have never made any guarantee
>> that the binary format won't change from release to release.
>
> The problem here are libpq-style drivers which expose the binary format
> to the application.  The Java driver doesn't do that, but the Perl
> driver does.  (However, both transparently decode BYTEA values received
> in text format, which led to the compatibility issue.)

I can see where that could cause some headaches... but it seems to me
that if we take that concern seriously, it brings us right back to
square one. If breaking the binary format causes too much pain to
actually go do it, then we shouldn't change it until we're breaking
everything else anyway (i.e. new protocol version, as Tom suggested).

Even if you have version negotiation, it doesn't help that much in
this scenario. Drivers that know about the new protocol can
theoretically negotiate upward, but if they expose the binary format
to their users in turn then it's a can of worms: they then need to
negotiate with their client applications to see what version the
client is OK with, and then turn around and negotiate with the server
to that level and not higher. That strikes me as a lot of work for a
lot of people given the amount of improvement we can expect out of
this one change.

I think it's also worth noting that a GUC is not really a good
mechanism for negotiating the protocol version. GUCs can be changed
by the local administrator on a server-wide (or per-user, or
per-database, or per-user-and-database) basis, and that's not what you
want for a protocol negotiation. Every client will have to query the
server version and then decide whether to try to change it, and handle
errors if that fails. All of that is going to add start-up overhead
to connections, which will need to make multiple round trips to get
everything straightened out.

I think if the only way to make this change without excessive pain is
by having a good mechanism for negotiating the protocol version, then
we need to defer it to a future release. Now is not the time to
invent entirely new mechanisms, especially around just one example.
I'm OK with breaking it and adding a GUC for backward-compatibility,
but so far the other suggestions strike me as being not convincingly
well-enough engineered to stand the test of time, and whatever we do
here is going to be with us for quite a while.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company