Hello
I checked it and I got a small issue
bash-4.1$ patch -p1 < cardinality.patch
(Stripping trailing CRs from patch.)
patching file doc/src/sgml/array.sgml
(Stripping trailing CRs from patch.)
patching file doc/src/sgml/func.sgml
(Stripping trailing CRs from patch.)
patching file src/backend/utils/adt/arrayfuncs.c
(Stripping trailing CRs from patch.)
patching file src/include/catalog/pg_proc.h
(Stripping trailing CRs from patch.)
patching file src/include/utils/array.h
(Stripping trailing CRs from patch.)
patching file src/test/regress/expected/arrays.out
(Stripping trailing CRs from patch.)
patching file src/test/regress/sql/arrays.sql
not sure about source of this problem.
Function works correctly and I would this feature
Regards
Pavel
2014/1/18 Marko Tiikkaja <ma...@joh.to>
> On 1/12/14, 5:53 AM, I wrote:
>
>> On 1/9/14, 2:57 PM, Dean Rasheed wrote:
>>
>>> How it should behave for multi-dimensional arrays is less clear, but
>>> I'd argue that it should return the total number of elements, i.e.
>>> cardinality('{{1,2},{3,4}}'::int[][]) = 4. That would make it
>>> consistent with the choices we've already made for unnest() and
>>> ordinality:
>>> - cardinality(foo) = (select count(*) from unnest(foo)).
>>> - unnest with ordinality would always result in ordinals in the range
>>> [1, cardinality].
>>>
>>
>> Ignoring my proposal, this seems like the most reasonable option. I'll
>> send an updated patch along these lines.
>>
>
> Here's the patch as promised. Thoughts?
>
>
> Regards,
> Marko Tiikkaja
>
