2014-09-27 14:00 GMT+02:00 Stephen Frost <sfr...@snowman.net>: > Andrew, all, > > * Andrew Dunstan (and...@dunslane.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 >
