Обсуждение: 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!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
Вложения
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@gmx.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@postgresql.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@gmx.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@gmx.net>: > Pavel Stehule wrote: >> >> Hello >> >> 2008/11/5 Peter Eisentraut <peter_e@gmx.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@gmx.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@decibel.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@gmx.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@gmx.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. >> >