From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inconsistent behavior on Array & Is Null? |
Date: | 2004-04-02 16:16:03 |
Message-ID: | 406D91C3.7060204@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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) as x;
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-02 16:16:21 | Re: Large DB |
Previous Message | Manfred Koizar | 2004-04-02 15:17:50 | Re: Large DB |