On Tue, Jan 24, 2012 at 8:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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:
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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2012-01-25 02:55:58|
|Subject: Fix for pg_upgrade tablespace function usage|
|Previous:||From: Tom Lane||Date: 2012-01-25 01:13:48|
|Subject: Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements |