Re: json (b) and null fields

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json (b) and null fields
Date: 2014-09-29 15:19:39
Message-ID: 5429788B.7020608@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 09/29/2014 10:38 AM, Robert Haas wrote:
> On Sat, Sep 27, 2014 at 11:00 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> On 09/27/2014 10:52 PM, Tom Lane wrote:
>>> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-29 15:20:48 Re: [REVIEW] Re: Compression of full-page-writes
Previous Message Robert Haas 2014-09-29 15:07:16 Re: [v9.5] Custom Plan API