From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: json (b) and null fields |
Date: | 2014-09-29 19:23:31 |
Message-ID: | CAFj8pRD29_FX3eTzHHBRcn_9uFa=ycyXRDQNKRZjF1tiJYD8AA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-09-27 14:00 GMT+02:00 Stephen Frost <sfrost(at)snowman(dot)net>:
> Andrew, all,
>
> * Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> > I should have been paying a bit more attention to the recent work on
> > adding an ignore_nulls option to row_to_json(). Here are some
> > belated thought. I apologize to Pavel and Stephen for not having
> > commented earlier.
>
> No problem at all and thanks for continuing to think about it! We
> certainly still have quite a bit of time til 9.5 to get this right.
>
> > I think this is really a bandaid, and it will fail to catch lots of
> > cases. Several examples:
>
> As discussed on IRC- I agree. I tend to think of JSON objects as
> relatively simple hstore-like structures and so hadn't considered the
> complex structure case (as I'm guessing Pavel hadn't either).
>
> > I think a much more comprehensive solution would be preferable. What
> > I have in mind is something like
> >
> > json_strip_null_fields(json) -> json
> >
> > and a similar function for jsonb.
>
> Right, this makes sense to me.
>
It is better than nothing, but it is not nice for JSON due 2x parsing.
Probably it is not issue for jsonb.
It is not nice, but I have not better .. and it will be faster than any
custom solution in plpgsql.
Personally, I am not sure, maybe is better to fix row_to_json
Regards
Pavel
>
> > These would operate recursively. There is a downside, in that they
> > would be required to reprocess the json/jsonb. But adding an option
> > like this to all the json generator functions would be seriously
> > ugly, especially since they are mostly aggregate functions or
> > variadic functions. At least in the jsonb case the cost of
> > reprocessing is likely to be fairly low.
>
> Yeah, I don't see adding this option to all json generator functions as
> making a lot of sense but rather just to the select few things which it
> really makes sense for and then having a function which can be used by
> users to do the same for results from other operations.
>
> Thanks!
>
> Stephen
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-29 19:24:55 | Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?) |
Previous Message | Pavel Stehule | 2014-09-29 19:17:44 | Re: json (b) and null fields |