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

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