Re: array_length()

ISTM it'd be useful to have an array_length function (since I just
wrote one for work ;), so here's a patch. Note that I don't have the
docs toolchain setup, so I wasn't able to test the doc patches.

Decibel! wrote:
> ISTM it'd be useful to have an array_length function (since I just wrote
> one for work ;), so here's a patch. Note that I don't have the docs
> toolchain setup, so I wasn't able to test the doc patches.

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.

Hello

2008/11/5 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> Decibel! wrote:
>>
>> ISTM it'd be useful to have an array_length function (since I just wrote
>> one for work ;), so here's a patch. Note that I don't have the docs
>> toolchain setup, so I wasn't able to test the doc patches.
>
> 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.
>

we should to write function isempty(anyarray), that returns true when
param is empty.

regards
Pavel Stehule

>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Pavel Stehule wrote:
> Hello
>
> 2008/11/5 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>> Decibel! wrote:
>>> ISTM it'd be useful to have an array_length function (since I just wrote
>>> one for work ;), so here's a patch. Note that I don't have the docs
>>> toolchain setup, so I wasn't able to test the doc patches.
>> 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.
>>
>
> we should to write function isempty(anyarray), that returns true when
> param is empty.

Well, isn't isempty() just a special case of array_length()? One or the
other needs to be implemented, so we might as well go for the general
case, IMO.

2008/11/5 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> Pavel Stehule wrote:
>>
>> Hello
>>
>> 2008/11/5 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>>>
>>> Decibel! wrote:
>>>>
>>>> ISTM it'd be useful to have an array_length function (since I just wrote
>>>> one for work ;), so here's a patch. Note that I don't have the docs
>>>> toolchain setup, so I wasn't able to test the doc patches.
>>>
>>> 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.
>>>
>>
>> we should to write function isempty(anyarray), that returns true when
>> param is empty.
>
> Well, isn't isempty() just a special case of array_length()? One or the
> other needs to be implemented, so we might as well go for the general case,
> IMO.
>

sure, but I believe so 90% of using array_length will be test of emty array.

Pavel

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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.

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.

regards, tom lane

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

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

Ugh. I meant rather:

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

...Robert

Updated version attached, this time without the compiler warning.

Sorry for the sloppy work.

...Robert

On Nov 5, 2008, at 7:00 AM, Peter Eisentraut wrote:
> 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.

What other error conditions? If we hit a real error, we should throw
an error.

Granted, there is some debate possible about what referencing an un-
defined dimension means, but I can't see how the results of that
should vary between array_length and array_lower/upper.

Is there some other corner case?
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Robert Haas wrote:
> Updated version attached, this time without the compiler warning.

I have committed something based on this. The issue of empty arrays
will need a separate solution.

Hmm, ISTM that cardinality() is implemented here in the manner
previously rejected for array_length()...

...Robert

On Wed, Nov 12, 2008 at 8:13 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Robert Haas wrote:
>>
>> Updated version attached, this time without the compiler warning.
>
> I have committed something based on this. The issue of empty arrays will
> need a separate solution.
>

Robert Haas wrote:
> Hmm, ISTM that cardinality() is implemented here in the manner
> previously rejected for array_length()...

The objection was that basic functionality should not be implemented in
SQL. If we want to disallow all compatibility functions implemented in
SQL as well, we have more work to do.

>
> ...Robert
>
> On Wed, Nov 12, 2008 at 8:13 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> Robert Haas wrote:
>>> Updated version attached, this time without the compiler warning.
>> I have committed something based on this. The issue of empty arrays will
>> need a separate solution.
>>
>