* 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@bfk.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
