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

On Tue, Jan 24, 2012 at 8:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, the bytea experience was IMNSHO a complete disaster (It was
>> earlier mentioned that jdbc clients were silently corrupting bytea
>> datums) and should be held up as an example of how *not* to do things;
>
> Yeah.  In both cases, the (proposed) new output format is
> self-identifying *to clients that know what to look for*.Unfortunately
> it would only be the most anally-written pre-existing client code that
> would be likely to spit up on the unexpected variations.  What's much
> more likely to happen, and did happen in the bytea case, is silent data
> corruption.  The lack of redundancy in binary data makes this even more
> likely, and the documentation situation makes it even worse.  If we had
> had a clear binary-data format spec from day one that told people that
> they must check for unexpected contents of the flag field and fail, then
> maybe we could get away with considering not doing so to be a
> client-side bug ... but I really don't think we have much of a leg to
> stand on given the poor documentation we've provided.
>
>> In regards to the array optimization, I think it's great -- but if you
>> truly want to avoid blowing up user applications, it needs to be
>> disabled automatically.
>
> Right.  We need to fix things so that this format will not be sent to
> clients unless the client code has indicated ability to accept it.
> A GUC is a really poor proxy for that.

OK.  It seems clear to me at this point that there is no appetite for
this patch in its present form:

https://commitfest.postgresql.org/action/patch_view?id=715

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company