Re: Inconsistent behavior on Array & Is Null?

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

In response to

Responses

Browse pgsql-hackers by date

  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