On Fri, Apr 29, 2016 at 12:31 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Thanks Alex for finding the previous thread. > > Andrew Dunstan wrote: >> >> On 04/28/2016 04:29 PM, Alvaro Herrera wrote: > >> >Actually we did have someone come up with a patch to "normalize" how >> >JSON stuff was output, because our code seems to do it in three >> >different, inconsistent ways. And our response was for them to get the >> >heck outta here, because we're so much in love with our current >> >practice that we don't need to refactor the three implementations into a >> >single one. >> That's a pretty bad mischaracterization of the discussion. > > Sorry, I don't agree with that. > >> What was proposed >> was broken, as I pointed out to the OP, and then again later to you when you >> asked about it. > > I didn't find your argument convincing back then, but this doesn't have > enough value to me that I can spend much time arguing about it. > >> I wouldn't necessarily be opposed to us having one or more of the following: >> >> a) suppressing whitespace addition in all json generation and text output, >> possibly governed by a GUC setting so we could maintain behaviour >> compatibility if required > > Sounds great to me, because we can unify the code so that we have *one* > piece to convert json to text instead of N, and not worry about the > non-relevant whitespace.
hurk -- no objection to unifying the text serialization code (if that proves reasonable to do). However I think using GUC to control output format is not a good idea. We did this for bytea and it did not turn out well; much better to have code anticipating precise formats to check the server version. This comes up over and over again: the GUC is not a solution for backwards compatibility...in fact, it's pandora's box (see: https://dev.mysql.com/doc/refman/5.5/en/sql-mode.html) . merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
