Greg Stark wrote:
> 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.
Sorry, but I still disagree. There *is* something unknown about the
lower and upper bound of an empty array because there are no bounds.
> 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 ?
I don't see the spec defined CARDINALITY as a workaround. It defines
length as the number of elements in the array. When the array is empty,
that value is clearly 0. Nothing strange about it.
> 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:
> test=# select array_upper(a||b, 1), array_upper(a,1)+array_length(b) from (select '{}'::int[] as a, array[1,2] as b)
asx;
> array_upper | ?column?
> -------------+----------
> 2 |
> (1 row)
OK, you got me with this corner case. But using what you described as
the result int_aggregate would give you in this case (-1), you would get
an even stranger answer (-1 + 2 = 1) that would still need to be worked
around.
Joe