On Mon, Jan 23, 2012 at 5:34 PM, Robert Haas <robertmh...@gmail.com> 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).
My suggestion - please avoid per-session-protocol. Either something is Postgres version-dependent or it can be toggled/tracked per request. That means any data can either be passed through, or you need to understand formats of Postgres version X.Y. This kind of hints at per-request "gimme-formats-from-version-x.y" flag for ExecuteV4 packet. Or some equivalent of it. Anything that cannot be processed without tracking per-session state over whole stack (poolers/client frameworks) is major pain to maintain. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers