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

On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> 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?

It sets that bit *and* version code - which means that it is
up-to-date with all "well-known" type formats in that version.

The key here is to sanely define the "well-known" types
and document them, so clients can be uptodate with them.

Variants:
- All built-in and contrib types in some Postgres version
- All built-in types in some Postgres version
- Most common types (text, numeric, bytes, int, float, bool, ..)

Also, as we have only one bit, the set of types cannot be
extended. (Unless we provide more bits for that, but that
may get too confusing?)

Basically, I see 2 scenarios here:

1) Client knows the result types and can set the
text/bin/version code safely, without further restrictions.

2) There is generic framework, that does not know query contents
but can be expected to track Postgres versions closely.
Such framework cannot say "binary" for results safely,
but *could* do it for some well-defined subset of types.

Ofcourse it may be that 2) is not worth supporting, as
frameworks can throw errors on their own if they find
format that they cannot parse. Then the user needs
to either register their own parser, or simply turn off
optmized formats to get the plain-text values.

--
marko