Joe Conway <mail@joeconway.com> writes:
> 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.
Not incorrect, but a sign something weird is going on. It should only happen
if the certain functions really are looking for some property that isn't known
for that peculiar value of their parameters. iscomputable(n) perhaps, sqrt(-1)
if we abuse the rules a bit. But array_upper for a non-null array?
array_lower() and array_upper() are returning NULL for a non-null input, the
empty array, even though lower and upper bounds are known just as well as they
are for any other sized array. They are behaving as if there's something
unknown about the empty array that makes it hard to provide a lower bound or
upper bound.
slo=> select array_lower('{}'::int[],1), array_upper('{}'::int[],1);array_lower | array_upper
-------------+------------- |
(1 row)
I know it's possible to work around this special case, but I'm saying it's odd
to have an irregularity in the interface. What justification is there for
breaking the invariant length = upper-lower+1 ?
Yes I read the examples you gave, but you a) had to work around the nit with a
special case in your function and b) still have corner cases where one of the
invariants I named fails, namely:
> 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:
test=# select array_upper(a||b, 1), array_upper(a,1)+array_length(b) from (select array[1,2] as a, array[1,2] as b) as
x;array_upper| ?column?
-------------+---------- 4 | 4
(1 row)
test=# select array_upper(a||b, 1), array_upper(a,1)+array_length(b) from (select '{}'::int[] as a, array[1,2] as b) as
x;array_upper| ?column?
-------------+---------- 2 |
(1 row)
--
greg