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