Re: proposal: searching in array function - array_position

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

In response to

Responses

Browse pgsql-hackers by date

  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