On Jan10, 2014, at 15:10 , Merlin Moncure <mmonc...@gmail.com> wrote:
> 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:
Sorry, I misunderstood what you were proposing. I though you intended
unnest_dims to returns one row per dimension, containing the index and
bounds of that dimension. And yeah, that fact your your mail showed
unnest_dims returning *4* rows for a *2*-dimensional array should have
tipped me off.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
