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 11:40:28AM -0500, Tom Lane wrote:
>> 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...

That is really not going to work if the requirement is to not break old
apps. They haven't read the 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.

Hmm, that adds yet another level of not-obvious-how-to-meet requirement.
I tend to concur with Robert that we are not close to a solution.

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

So in other words, if we have a client that contains a framework that
knows about version N, and we connect it up to a server that speaks
version N+1, it suddenly loses the ability to use any version-N
optimizations? That does not meet my idea of not breaking old apps.

regards, tom lane