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

On Mon, Jan 23, 2012 at 11:06 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jan 23, 2012 at 11:15 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> 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.
>
> Sure, it's not directly related to the active protocol version, but my
> point is that we need to decide whether we need an autonegotiation
> mechanism or some kind, or not.  We can reasonably decide that:
>
> 1. It's OK to change the binary format incompatibly, and clients must
> be prepared to deal with that, possibly assisted by a
> backward-compatibility GUC.
>
> -or else-
>
> 2. It's not OK to change the binary format incompatibility, and
> therefore we need some kind of negotiation mechanism to make sure that
> we give the new and improved format only to clients that can cope with
> it.
>
> Not being responsible from the maintenance of any PostgreSQL drivers
> whatsoever, I don't have a strong feeling about which of these is the
> case, and I'd like us to hear from the people who do.  What I do think
> is that we can't look at a GUC (however named) as a poor man's
> replacement for #2.  It's not gonna work, or at least not very well.
> If the default is off, then clients have to go through a round-trip to
> turn it on, which means that every client will have to decide whether
> to pay the price of turning it on (and possibly not recoup the
> investment) or whether to leave it off (and possibly get hosed if many
> large arrays that would have met the criteria for the optimization are
> transferred).  Furthermore, if we turn it on by default, drivers and
> applications that haven't been updated will deliver corrupted results.
>  None of that sounds very good to me.  If there are enough
> dependencies on the details of the binary format that we can't afford
> to just change it, then we'd better have a cheap and reliable way for
> clients to negotiate upward - and a GUC is not going to give us that.

Trying to solve it with startup-time negotiation, or some GUC
is a dead end, in the sense that it will actively discourage any
kind of pass-through protocol processing. If simple protocol
processor (~pgbouncer) needs to know about some GUC,
and tune it on-the-fly, it's not a payload feature, it's a protocol feature.

Instead this should be solved with extending the per-query text/bin
flag to include version info and maybe also type groups.
Some way of saying "numerics:9.0-bin", "the-rest:8.4-text".

The groups would also solve the problem with no way
of turning on binary formats on result columns safely.

The flags could be text (~http accept), or maybe integers
for more efficiency (group code: group format ver).

--
marko