On 11/24/2011 02:36 AM, Kevin Grittner wrote:
> Oliver Jowett wrote:
>
>> Can we get a mechanism for minor protocol changes in this future
>> version? Something as simple as exchanging a list of protocol
>> features during the initial handshake (then use only features that
>> are present on both sides) would be enough. The difficulty of
>> making any protocol changes at the moment is a big stumbling block.
>
> I've been thinking the same thing. Any new protocol should include a
> way for each side to publish a list of what it can accept from the
> other during initial handshaking.
>
>> (You could probably retrofit that to the current protocol version)
>
> Perhaps. It would be great if both sides could recognize the case
> where the "feature negotiation" was absent and use a default feature
> list for the protocol available on the other end.
What about a hand-shake protocol based on simple binary-protocol minor
version instead of features. We keep the v3 protocol as is but can
add cumulative conditionally enabled features when we bump the minor
version.
The hand shake requires that the server sends a parameter back with
it's highest supported minor version:
FE=> StartupPacket
<=BE ParameterStatus(binary_minor = 23)
And the client can send any number between 1<=binary_minor back to
enable newer protocol versions and/or limit what the server sends
FE=> Execute(SET binary_minor = 20)
To keep full backwards compatibility:
1) if backend does not send a binary_minor parameter on connection the
highest supported minor version is assumed to be 0 (current format)
2) the backend assumes the active minor version is 0 unless the
SET binary_minor is received
I think bumping a minor version is better than feature flags because:
1) the hand shake is simpler and faster
2) coding is easier as all previous features are known to be supported
and active when implementing feature+1
I'm not exactly sure about the COPY BINARY feature Tom mentioned. But
probably we could prefix the data with the int4 containing the
minor version?
-Mikko
