Re: json (b) and null fields

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:28:06
Message-ID: CAFj8pRDx0jnpeQSkbU+6-haioVoLSAiJrr69uFPdVitHB=aDHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-09-29 21:23 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

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

we can use a different name like row_to_json_strip_null

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-29 19:37:33 Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)
Previous 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?)