Re: Inconsistent behavior on Array & Is Null?

Greg Stark wrote:

> Joe Conway <mail(at)joeconway(dot)com> writes:
>>Same here; this would be:
>>
>>array_upper(a || b) == array_upper(a) + CARDINALITY(b)
>>
>>and would work just fine. Note that if array-a is NULL, then the spec defines a
>>|| b as NULL. See section 6.35:
>
> Why are you talking about when a is NULL? The original question was for when a
> was an empty array. That's not an unknown value, it's known to be an array
> containing no elements.

Did you even look at my examples at the end of the post? I showed your
example, with an empty array, handled correctly. The mention of a NULL
array was only for completeness.

> It sounds like this is the same type of confusion that led to Oracle treating
> empty strings as NULL, which causes no end of headaches.

ISTM that you're the one who's confused. There is a very clear
distinction between a NULL array and an empty array in the present
implementation. They are *not* treated the same:

regression=# select '{}'::int[], NULL::int[];
int4 | int4
------+------
{} |
(1 row)

regression=# select '{}'::int[] is NULL, NULL::int[] is NULL;
?column? | ?column?
----------+----------
f | t
(1 row)

You seem to be saying that because the output of certain functions that
operate on empty arrays is NULL, it somehow implies that the array is
being treated as NULL -- that's just plain incorrect.

> My argument was that having to write a special case here makes it pretty clear
> the idea of equating {} with NULL is the wrong interface.

But they're not being equated (see above), so I don't see where there's
an issue.

Joe