Re: proposal: searching in array function - array_position - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: searching in array function - array_position
Date
Msg-id CAFj8pRC8-vzy+LAd6b-LS9pSbjgHCgbfreNZHZeePJcd=c1u-w@mail.gmail.com
Whole thread Raw
In response to Re: proposal: searching in array function - array_position  (Marko Tiikkaja <marko@joh.to>)
Responses Re: proposal: searching in array function - array_position  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers


2015-03-18 12:41 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On 3/18/15 12:27 PM, Pavel Stehule wrote:
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.

I designed this possibility (use ND arrays)
mainly for info, if some value exists or not.

Why not use =ANY() for that?

It is only partial solution - array_offset use "IS NOT DISTINCT FROM" operator.

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.

A nonsensical answer for multi-dimensional arrays is worse than no answer at all.  I think raising an exception is better.

I have not problem with it.

Regards

Pavel
 


.m

pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: proposal: searching in array function - array_position
Next
From: Robert Haas
Date:
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)