Re: [PATCH] Generalized JSON output functions

On Sat, May 23, 2015 at 3:03 AM, Ryan Pedela <rpedela(at)datalanche(dot)com> wrote:

> On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure <mmoncure(at)gmail(dot)com>
> wrote:
>
>> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)com> wrote:
>> > Andrew Dunstan wrote:
>> >>
>> >> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
>> >
>> >> >Attached is a patch against master to generalize the JSON-producing
>> >> >functions in utils/adt/json.c and to provide a set of callbacks which
>> can
>> >> >be overridden the same way that is already provided for *parsing*
>> JSON.
>> >
>> >> I'm not necessarily opposed to this, but it sure seems like a lot of
>> >> changes, and moderately invasive ones, to support something that could
>> be
>> >> done, at the cost of reparsing, with a simple loadable extension that I
>> >> could create in a few hours of programming.
>> >
>> > But this seems like a pretty reasonable change to make, no? Doesn't the
>> > total amount of code decrease after this patch? JSON stuff is pretty
>> > new so some refactoring and generalization of what we have is to be
>> > expected.
>>
>> Yeah. Also, there have been a few previous gripes about this, for
>> example,
>> http://www.postgresql.org/message-id/CAHbVmPzS+sVR+y-UgxjRq+XW4dqteVL-cOzc69zFFwmxjcKCxg@mail.gmail.com
>> .
>> As noted, I definitely prefer 'space free' by default for efficiency
>> reasons, but standardizing the output has definitely got to be a
>> reasonable goal.
>>
>
> Every JSON implementation I have ever used defaults to the minified
> version of JSON (no whitespace) when printed.
>

Hashing of arrays seems to be an important issue: we'd rather make sure to
produce the same output in every code path. That would also mean: no
special logic to add the line feeds in json_agg either.

Is it reasonable to add this patch to CommitFest now?

--
Alex