On 09/29/2014 10:38 AM, Robert Haas wrote:
On Sat, Sep 27, 2014 at 11:00 PM, Andrew Dunstan <and...@dunslane.net> wrote:
On 09/27/2014 10:52 PM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 09/27/2014 06:27 PM, Tom Lane wrote:
So my vote is for a separate function and no optional arguments.
You mean like row_to_json_no_nulls() and json_agg_no_nulls()?
I thought you were proposing that we should revert the committed patch
lock-stock-n-barrel, and instead invent json_strip_null_fields().
That's instead, not in addition to.  Even if you weren't saying that
exactly, that's where my vote goes.
I was just exploring alternatives. But I think that's where my vote goes
too.
+1.  I am sort of surprised that anyone things this null-stripping
behavior is something that ought to be part of core PostgreSQL instead
of, I don't know, relegated to an extension somewhere far from the
bright center of the galaxy.  I've never heard of that requirement
anywhere but here.  But if other people feel we should have it, that's
fine - but certainly making it a separate function makes a lot more
sense.



Fetching data from a missing field should return null, so stripping null fields can give you in effect the same result, depending on what your app does, without actually having to store the key and the null. And if we're producing JSON for an external processor from a table that is fairly sparsely populated, this could reduce the size of the JSON enormously.

That said, doing this as an extension is probably a good way to go, as I suggested upthread, since we could then make it available for 9.4, rather than making people wait until 9.5.

cheers

andrew




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to