Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
Date
Msg-id CAHyXU0zST1SFM5syBEMxOG4uMpTKpysgFUnkPqQSSkCZedG_JA@mail.gmail.com
Whole thread Raw
In response to Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements  ("A.M." <agentm@themactionfaction.com>)
Responses Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
List pgsql-hackers
On Mon, Jan 23, 2012 at 2:00 PM, A.M. <agentm@themactionfaction.com> wrote:
> One simple way clients could detect the binary encoding at startup would be to pass known test parameters and match
againstthe 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
andthen clients can specify the highest "version" of the binary format which they support.
 

Prefer the version.  But why send this over and over with each bind?
Wouldn't you negotiate that when connecting? Most likely, optionally,
doing as much as you can from the server version?  Personally I'm not
really enthusiastic about a solution that adds a non-avoidable penalty
to all queries.

Also, a small nit: this problem is not specific to binary formats.
Text formats can and do change, albeit rarely, with predictable
headaches for the client.  I see no reason to deal with text/binary
differently.  The only difference between text/binary wire formats in
my eyes are that the text formats are documented.

merlin


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL return value in after triggers