Re: proposal: searching in array function - array_position

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: proposal: searching in array function - array_position
Date: 2015-03-18 11:27:29
Message-ID: CAFj8pRC2U_RCNuOhP-VeGtNoDOsd6yZC0T6B+jjD2KYYc1HQ+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-03-18 3:45 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2015-03-18 11:41:51 Re: proposal: searching in array function - array_position
Previous Message Dean Rasheed 2015-03-18 09:59:33 Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0