Re: json (b) and null fields
От | Stephen Frost |
---|---|
Тема | Re: json (b) and null fields |
Дата | |
Msg-id | 20140927120009.GG16422@tamriel.snowman.net обсуждение исходный текст |
Ответ на | json (b) and null fields (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: json (b) and null fields
Re: json (b) and null fields |
Список | pgsql-hackers |
Andrew, all, * Andrew Dunstan (andrew@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. > 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
В списке pgsql-hackers по дате отправления: