Re: Inconsistent behavior on Array & Is Null?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inconsistent behavior on Array & Is Null?
Date: 2004-04-02 06:00:51
Message-ID: 87vfkior58.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:

> 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:

Why are you talking about when a is NULL? The original question was for when a
was an empty array. That's not an unknown value, it's known to be an array
containing no elements.

It sounds like this is the same type of confusion that led to Oracle treating
empty strings as NULL, which causes no end of headaches.

> Anyway, CARDINALITY is what you really need -- hopefully I'll be able to find
> time to address that and some ather array items before the 7.5 freeze. In the
> meantime, if you have a custom array_length function already, why not make it
> return 0 for empty arrays -- then your problems disappear:
>
> create or replace function array_length(anyarray)
> returns int as '
> select
> case
> when $1 = ''{}'' then 0
> else array_upper($1, 1) - array_lower($1, 1) + 1
> end
> ' language sql;

My argument was that having to write a special case here makes it pretty clear
the idea of equating {} with NULL is the wrong interface.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-04-02 06:17:10 Re: pre-loading a user table.
Previous Message Joe Conway 2004-04-02 05:43:23 Re: Inconsistent behavior on Array & Is Null?