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
