On Mon, Jan 23, 2012 at 5:34 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jan 23, 2012 at 9:36 AM, Florian Weimer <fweimer@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
