2015-03-18 3:45 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>:
> On 3/17/15 8:06 PM, Alvaro Herrera wrote:
>
>> My main question regarding this patch is whether the behavior with MD
>> arrays is useful at all. Suppose I give it this:
>>
>> alvherre=# select array_offset('{{{1,2},{3,4},{5,6}},{{2,3},{4,5},{6,7}}}',
>> 3);
>> array_offset
>> --------------
>> 3
>> (1 fila)
>>
>> What can I do with the "3" value it returned? Certainly not use it as
>> an offset to get a slice of the original array. The only thing that
>> seems sensible to me here is to reject the whole thing with an error,
>> that is, only accept 1-D arrays here. We can later extend the function
>> by allowing higher dimensionality as long as the second argument is an
>> array one dimension less than the first argument. But if we allow the
>> case on its appearance, it's going to be difficult to change the
>> behavior later.
>>
>
This behave is consistent with "unnest" function, when all multidimensional
arrays are reduced to 1ND arrays.
Other argument for this behave is impossibility to design other behave.
array_offset function have to returns integer always. You cannot to returns
a array of integers, what is necessary for MD position. And one integer can
be only position in flatted 1ND array. I agree, so this is not user
friendly, but there is not any other possible solution - we have not
anyarray and anymdarray types. I designed this possibility (use ND arrays)
mainly for info, if some value exists or not.
I am thinking, so this behave is correct (there is no other possible), but
it is only corner case for this functionality - and if you are thinking, so
better to disallow it, I am not against. My main focus is 1ND array.
Regards
Pavel
>
> +1
>
> Has a case been made for the current behavior?
>>
>
> Not that I remember. There was discussion about how this should properly
> support MD arrays.
>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
