Greg Stark wrote:
> Joe Conway <mail@joeconway.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