On Fri, Apr 29, 2016 at 12:31 PM, Alvaro Herrera
<alvherre@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
