Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements

On Jan 23, 2012, at 2:49 PM, Tom Lane wrote:

> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> [ bytea_output doesn't need to be GUC_REPORT because format is autodetectable ]
>
> Fair enough. Anyway we're really about two years too late to revisit that.
>
>> Btw, it does not seems that per-request metainfo change requires
>> "major version". It just client can send extra metainfo packet
>> before bind+execute, if it knows server version is good enough.
>
> That is nonsense. You're changing the protocol, and then saying
> that clients should consult the server version instead of the
> protocol version to know what to do.
>
>> 2. Can we postpone minor data format changes on the wire until there
>> is proper way for clients to request on-the-wire formats?
>
> I think that people are coming around to that position, ie, we need
> a well-engineered solution to the versioning problem *first*, and
> should not accept incompatible minor improvements until we have that.

One simple way clients could detect the binary encoding at startup would be to pass known test parameters and match against the returned values. If the client cannot match the response, then it should choose the text representation.

Alternatively, the 16-bit int in the Bind and RowDescription messages could be incremented to indicate a new format and then clients can specify the highest "version" of the binary format which they support.

Cheers,
M