On Fri, Jan 10, 2014 at 6:00 AM, Florian Pflug <f...@phlo.org> wrote:
> On Jan10, 2014, at 11:00 , Merlin Moncure <mmonc...@gmail.com> wrote:
>> On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja <ma...@joh.to> wrote:
>>> On 1/10/14, 10:41 AM, Merlin Moncure wrote:
>>>> What's needed for better iteration support (IMO)
>>>> is a function that does what unnest does but returns an array on
>>>> indexes (one per dimsension) -- a generalization of the
>>>> _pg_expandarray function.  Lets' say 'unnest_dims'.
>>> So  unnest_dims('{{1,2},{3,4}}'::int[])  would return  VALUES (1,
>>> '{1,2}'::int[]), (2, '{3,4}'::int[])?  If so, then yes, that's a
>>> functionality I've considered us to have been missing for a long time.
>> not quite.  it returns int[], anyelement: so, using your example, you'd get:
>> [1,1], 1
>> [1,2], 2
>> [2,1], 3
>> [2,2], 4
> Now that we have WITH ORDINALITY, it'd be sufficient to have a
> variant of array_dims() that returns int[][] instead of text, say
> array_dimsarray(). Your unnest_dims could then be written as
>   unnest(array_dimsarray(array)) with ordinality

hm, not quite following that.  maybe an example?

my issue with 'WITH ORDINALITY' (while it's pretty neat) is that it
doesn't give you the dimension coordinate of each datum so you can't
really use it to slice.  with unnest_dims(), you an slice, say via:

select array_agg(value) from (unnest_dims('{{1,2},{3,4}}'::int[])
group by dims[1];
select array_agg(value) from (unnest_dims('{{1,2},{3,4}}'::int[])
where dims[1] = 2;

not super elegant, but good enough for most uses I think.   anyways,
getting back on topic, the question on the table is cardinality() vs
array_length, right?


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to