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

From Robert Haas
Subject Re: json (b) and null fields
Date
Msg-id CA+TgmoaLhetdFz9v9ONZTQF48srOwKVjEexg8+FH=Yw1wLYQ4w@mail.gmail.com
Whole thread Raw
In response to Re: json (b) and null fields  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: json (b) and null fields  (Stephen Frost <sfrost@snowman.net>)
Re: json (b) and null fields  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Sat, Sep 27, 2014 at 11:00 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> On 09/27/2014 10:52 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew@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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: pgcrypto: PGP armor headers
Next
From: Tom Lane
Date:
Subject: Re: Patch to support SEMI and ANTI join removal