On Tue, Jan 24, 2012 at 8:13 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
