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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to