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

Marko Kreen <markokr(at)gmail(dot)com> writes:
> On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
>> Furthermore, while we haven't settled the question of exactly what a
>> good negotiation facility would look like, we seem to agree that a GUC
>> isn't it. I think that means this isn't going to happen for 9.2, so
>> we should mark this patch Returned with Feedback and return to this
>> topic for 9.3.

> Simply extending the text/bin flags should be quite
> uncontroversial first step. How to express the
> capability in startup packet, I leave to others to decide.

> But my proposal would be following:

> bit 0 : text/bin
> bit 1..15 : format version number, maps to best formats in some
> Postgres version.

> It does not solve the resultset problem, where I'd like to say
> "gimme well-known types in optimal representation, others in text".
> I don't know the perfect solution for that, but I suspect the
> biggest danger here is the urge to go to maximal complexity
> immediately. So perhaps the good idea would simply give one
> additional bit (0x8000?) in result flag to say that only
> well-known types should be optimized. That should cover 95%
> of use-cases, and we can design more flexible packet format
> when we know more about actual needs.

Huh? How can that work? If we decide to change the representation of
some other "well known type", say numeric, how do we decide whether a
client setting that bit is expecting that change or not?

regards, tom lane