From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | 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 02:45:02 |
Message-ID: | 5508E6AE.3080603@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
+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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-03-18 03:01:16 | Re: Reduce pinning in btree indexes |
Previous Message | Michael Paquier | 2015-03-18 01:58:00 | Re: Strange assertion using VACOPT_FREEZE in vacuum.c |