Re: [PATCH] Generalized JSON output functions

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Generalized JSON output functions
Date: 2015-05-22 07:12:09
Message-ID: CACACo5R=un+dHqPOVjNP-Cb3P+u_NRJo1P3gEG2xB0BjVV-b+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 21, 2015 at 6:43 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> On Thu, May 21, 2015 at 2:23 AM, Shulgin, Oleksandr
> <oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
> > On Wed, May 20, 2015 at 4:06 PM, Merlin Moncure <mmoncure(at)gmail(dot)com>
> wrote:
> >>
> >> On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr
> >> <oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
> >> >
> >> > a) no spaces
> >> >
> >> > select to_json(row(1,2));
> >> > to_json
> >> > -----------------
> >> > {"f1":1,"f2":2}
> >> >
> >> > b) some spaces (hstore_to_json)
> >> >
> >> > select hstore(row(1,2))::json;
> >> > hstore
> >> > ------------------------
> >> > {"f1": "1", "f2": "2"}
> >> >
> >> > c) spaces around colon
> >> >
> >> > select json_build_object('f1',1,'f2',2);
> >> > json_build_object
> >> > ----------------------
> >> > {"f1" : 1, "f2" : 2}
> >> >
> >> > d) spaces around colon *and* curly braces
> >> >
> >> > select json_object_agg(x,x) from unnest('{1,2}'::int[]) x;
> >> > json_object_agg
> >> > ----------------------
> >> > { "1" : 1, "2" : 2 }
> >> >
> >> > e) line feeds (row_to_json_pretty)
> >> >
> >> > select row_to_json(row(1,2), true) as row;
> >> > row
> >> > ----------
> >> > {"f1":1,+
> >> > "f2":2}
> >> >
> >> > Personally, I think we should stick to (b), however that would break a
> >> > lot
> >> > of test cases that already depend on (a). I've tried hard to minimize
> >> > the
> >> > amount of changes in expected/json.out, but it is quickly becomes
> >> > cumbersome
> >> > trying to support all of the above formats. So I've altered (c) and
> (d)
> >> > to
> >> > look like (b), naturally only whitespace was affected.
> >>
> >> Disagree. IMNSHO, the default should be (a), as it's the most compact
> >> format and therefore the fastest. Whitespace injection should be
> >> reserved for prettification functions.
> >
> >
> > I have no strong opinion on choosing (a) over (b), just wanted to make
> the
> > change minimally sensible. If at all, I think we should modify existing
> > code to make JSON output consistent: that is choose one format an stick
> to
> > it.
>
> sure -- did you mean to respond off-list?

No, just using an unusual mail agent :-p

> anyways, inserting spacing
> into the serialization function formatting (xx_to_json) for me will
> raise memory profile of output json by 10%+ in nearly all cases. I
> just don't see the benefit of doing that given that the json is still
> not very 'pretty'.
>

I can agree that spaces are only useful for a human being trying to make
sense of the data. My vote is for reasonable default + an option to put
spaces/prettify on demand.

--
Alex

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-05-22 07:22:07 Re: Add a hint when postgresql.conf hot_standby = 'off' and recovery.conf standby = 'on'
Previous Message Christian Ullrich 2015-05-22 06:44:10 Re: hstore_plpython regression test does not work on Python 3