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) .


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to