From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP json generation enhancements |
Date: | 2012-11-26 19:46:36 |
Message-ID: | 50B3C71C.5060906@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Hannu Krosing
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2012-11-26 19:49:23 | Re: WIP: index support for regexp search |
Previous Message | Alvaro Herrera | 2012-11-26 19:45:55 | Re: foreign key locks |