On Thu, May 21, 2015 at 6:43 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
On Thu, May 21, 2015 at 2:23 AM, Shulgin, Oleksandr
<oleksandr.shulgin@zalando.de> wrote: > On Wed, May 20, 2015 at 4:06 PM, Merlin Moncure <mmoncure@gmail.com> wrote: >> >> On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr >> <oleksandr.shulgin@zalando.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.