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