Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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: array_length.patch
Description: text/x-diff (4.7 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2008-11-07 03:56:13
Subject: Re: array_length()
Previous:From: KaiGai KoheiDate: 2008-11-07 03:13:08
Subject: Re: The suppress_redundant_updates_trigger() works incorrectly

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group