Re: array_length()

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, Decibel! <decibel(at)decibel(dot)org>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: array_length()
Date: 2008-11-07 03:51:23
Message-ID: 603c8f070811061951u16034c3fk5dfaa493a6739a24@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> There is a tiny problem with this implementation: It returns null for an
>> empty array, not zero. This is because array_lower and/or array_upper
>> return null for an empty array, which makes sense for those cases. We
>> could fix this by putting a coalesce around the expression, but since
>> the array functions return null for all kinds of error cases, this might
>> mask other problems. Or we move to a C implementation.

Hmm... the problem is that an empty array is really zero-dimensional.
So for what values of the second argument ought we to return 0?

It certainly seems inconsistent to say that array_length({}, 6) = 0
and array_length({1}, 6) is null.

We do need a good way to test for an empty array, though. Right now I
think the best ways is array_ndims(x) IS NULL (should it return 0
rather than NULL on an empty array?).

> Basic functionality like this shouldn't be implemented as a SQL function
> anyway. People don't expect that some built-in functions should be
> several orders of magnitude slower than other built-in functions of
> apparently similar complexity.

C implementation attached.

...Robert

Attachment Content-Type Size
array_length.patch text/x-diff 4.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2008-11-07 03:56:13 Re: array_length()
Previous Message KaiGai Kohei 2008-11-07 03:13:08 Re: The suppress_redundant_updates_trigger() works incorrectly