On 04/29/2016 02:34 PM, Merlin Moncure wrote:
>>> 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) .
>
OK, fine by me. It's trivial to do for jsonb - all the white space comes
from on function, AFAIK. For json it's a bit more spread out, but only
in one or two files. Here's a question: say we have this table:
mytable:(x text, y json). now we do: "select to_json(r) from mytable r;"
Now y is a json field, which preserves the whitespace of the input. Do
we squash the whitespace out or not when producing the output of this
query? I'm inclined to say yes we do, but it's not a slam-dunk no-brainer.
One other point: I think we really need most of these pieces - if we are
going to squash the whitespace we need functions to do that cleanly for
json and to pretty-print json.
cheers
andrew
