On Mon, Jan 23, 2012 at 10:34:12AM -0500, Robert Haas wrote: > On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer <fwei...@bfk.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).
As I said upthread, and you appeared to agree, the protocol is independent of individual data type send/recv formats. Even if we were already adding protocol v4 to PostgreSQL 9.2, having array_send() change its behavior in response to the active protocol version would be wrong. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
