Re: Inconsistent behavior on Array & Is Null?

From: Joe Conway <mail(at)joeconway(dot)com>
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inconsistent behavior on Array & Is Null?
Date: 2004-04-02 02:29:03
Message-ID: 406CCFEF.2080203@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus wrote:
> What about a 0? That seems more consistent to me. If the array
> is empty, its dimensions are not "NULL", meaning "unknown", but in
> fact zero elements, which is a known value.

They cannot be 0 because 0 is a real index. They are undefined, because
an empty array has no dimensions. It is entirely possible to have a real
array that starts at a lower bound of 0 (or even an upper bound of 0).

regression=# select f[0] from (select 99 || array[1,2,3] as f) as t;
f
----
99
(1 row)

regression=# create table a1 (f int[]);
CREATE TABLE
regression=# insert into a1 values('{}');
INSERT 18688045 1
regression=# update a1 set f[0] = 99;
UPDATE 1
regression=# select array_upper(f,1) from a1;
array_upper
-------------
0
(1 row)

> The way it works now, array_upper on a NULL array produces the same
> results as array_upper on an empty-but-non-null array.

Sure, and in both cases array_upper is undefined because there are no
array dimensions to speak of. I guess you might argue that array_upper,
array_lower, and array_dims should all produce an ERROR on null input
instead of NULL. But that would have been an un-backward compatible
change for array_dims at the time array_lower and array_upper were
created. I don't really believe they should throw an ERROR on an empty
array though.

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2004-04-02 03:04:41 Re: PITR for replication?
Previous Message Gavin Sherry 2004-04-02 01:50:36 Re: PITR for replication?