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

From: Florian Weimer <fweimer(at)bfk(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Mikko Tiihonen <mikko(dot)tiihonen(at)nitorcreations(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility
Date: 2012-01-23 14:36:01
Message-ID: 82d3aa4hbi.fsf@mid.bfk.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* 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.)

If you've version negotiation and you don't expose the binary format,
then all clients can use the most efficient format automatically. If I
understand things correctly, this is where the JDBC driver is heading
(that is, automatic use of binary format).

--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2012-01-23 14:49:56 Re: PG-Strom - A GPU optimized asynchronous executor module
Previous Message Simon Riggs 2012-01-23 14:31:58 Re: basic pgbench runs with various performance-related patches