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

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.

libpq suggestions:

PQsetformatcodes(bool)
only if its called with TRUE, it starts interpreting
text/bin codes as non-bools. IOW, we will be compatible
with old code using -1 as TRUE.

protocol suggestions:

On startup server sends highest supported text/bin codes,
and gives error if finds higher code than supported.
Poolers/proxies with different server versions in pool
will simply give lowest common code out.

Small Q&A, to put obvious aspects into writing
----------------------------------------------

* Does that mean we need to keep old formats around infinitely?

Yes. On-wire formats have *much* higher visibility than
on-disk formats. Also, except some basic types they are
not parsed in adapters, but in client code. Libpq offers
least help in that respect.

Basically - changing on-wire formatting is big deal,
don't do it willy-nilly.

* Does that mean we cannot turn on new formats automatically?

Yes. Should be obvious..

--
marko