Re: WIP json generation enhancements

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP json generation enhancements
Date: 2012-11-26 19:54:19
Message-ID: 50B3C8EB.1000403@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/26/2012 02:46 PM, Hannu Krosing wrote:
> On 11/26/2012 08:12 PM, Peter Eisentraut wrote:
>> On 11/21/12 3:16 PM, Andrew Dunstan wrote:
>>> One open question regarding this feature is whether this should return
>>> NULL or '[]' for 0 rows. Currently it returns NULL but I could be
>>> convinced to return '[]', and the change would be very small.
>> Although my intuition would be [], the existing concatenation-like
>> aggregates return null for no input rows, so this probably ought to be
>> consistent with those.
>>
> In some previous mail Tom Lane claimed that by SQL standard
> either an array of all NULLs or a record with all fields NULLs (I
> don't remember which) is also considered NULL. If this is true,
> then an empty array - which can be said to consist of nothing
> but NULLs - should itself be NULL.
>
> If this is so, than the existing behaviour of returning NULL in such
> cases is what standard requires.
>
>

That would be more relevant if we were talking about postgres arrays,
but the '[]' here would not be a postgres array - it would be a piece of
json text.

But in any case, the consensus seems to be to return null, and on the
principle of doing the least work required I'm happy to comply.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-11-26 20:05:44 Re: WIP json generation enhancements
Previous Message Alexander Korotkov 2012-11-26 19:49:23 Re: WIP: index support for regexp search