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

On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> 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.

The "other negotiation" is done via Postgres release notes...

I specifically want to avoid any sort of per-connection
negotation, except the "max format version supported",
because it will mess up multiplexed usage of single connection.
Then they need to either disabled advanced formats completely,
or still do it per-query somehow (via GUCs?) which is mess.

Also I don't see any market for "flexible" negotations,
instead I see that people want 2 things:

- Updated formats are easily available
- Old apps not to break

I might be mistaken here, then please correct me,
but currently I'm designing for simplicity.

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

No, the list of "well-known" types is documented and fixed.
The bit is specifically for frameworks, so that they can say
"I support all well-known types in Postgres version X.Y".

Note I said that the list cannot be extended but that is wrong.
When this bit and version code are taken together, it clearly
defines "list as in version X.Y". So considering that
client should not send any higher version than server supports,
it means server always knows what list client refers to.

--
marko