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

On Mon, Nov 28, 2011 at 9:18 AM, Mikko Tiihonen
<mikko(dot)tiihonen(at)nitorcreations(dot)com> wrote:
> Hi,
>
> As discussed few days ago it would be beneficial if we could change the v3
> backend<->client protocol without breaking backwards compatibility.
>
> Here is a working patch that exports a supported_binary_minor constant and a
> binary_minor session variable and a that can be used by clients to enable
> newer features.
>
> I also added an example usage where the array encoding for constant size
> elements is optimized if binary_minor version is new enough.
>
> I have coded the client side support for binary_minor for jdbc driver and
> tested that it worked. But lets first discuss if this is an acceptable path
> forward.
>
> On 11/25/2011 02:20 AM, Oliver Jowett wrote:
>> Re list vs. always-incrementing minor version, you could just use an
>> integer and set bits to represent features, which would keep it simple
>> but also let clients be more selective about which features they
>> implement (you could support feature 21 and 23 without supporting 22)
>
> I decided not to use a feature flag because when features start to depend on
> each other we need multiple negotiation round trips until the final feature
> set can be known.
> If in your example above the feature 23 depends on server side on feature
> 22, but the client only requests 21,23. The server must inform back that
> combination 21,23 is reduced to 21. And if then the client can not support
> 21 without 23 the final feature set will not contain 21 or 23.

Regarding your TODO in the code comments about interactions with
replication: I think it should be removed. WAL streaming depends on
more things being identical than what is guaranteed here which is
basically the protocol + data formats. I think all references to
'protocol' should be removed; Binary wire formats != protocol: the
protocol could bump to v4 but the wire formats (by happenstance) could
all still continue to work -- therefore the version isn't minor (it's
not dependent on protocol version but only on itself). Therefore,
don't much like the name 'supported_binary_minor'. How about
binary_format_version?

Also, is a non granular approach really buying us anything here? ISTM
*something* is likely to change format on most releases of the server
so I'm wondering what's the point (if you don't happen to be on the
same x.x release of the server, you might as well assume to not match
or at least 'go on your own risk). The value added to the client
version query is quite low.

merlin