Re: json (b) and null fields - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: json (b) and null fields
Date
Msg-id CAFj8pRDx0jnpeQSkbU+6-haioVoLSAiJrr69uFPdVitHB=aDHw@mail.gmail.com
Whole thread Raw
In response to Re: json (b) and null fields  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


2014-09-29 21:23 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:


2014-09-27 14:00 GMT+02:00 Stephen Frost <sfrost@snowman.net>:
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.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)
Next
From: Andres Freund
Date:
Subject: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)