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

Then why bother with the bit in the format code? If you've already done
some other negotiation to establish what datatype formats you will
accept, this doesn't seem to be adding any value.

> 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.

The hole in approach (2) is that it supposes that the client side knows
the specific datatypes in a query result in advance. While this is
sometimes workable for application-level code that knows what query it's
issuing, it's really entirely untenable for a framework or library.
The only way that a framework can deal with arbitrary queries is to
introduce an extra round trip (Describe step) to see what datatypes
the query will produce so it can decide what format codes to issue
... and that will pretty much eat up any time savings you might get
from a more efficient representation.

You really want to do the negotiation once, at connection setup, and
then be able to process queries without client-side prechecking of what
data types will be sent back.

regards, tom lane