Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Date: 2010-12-17 17:03:24
Message-ID: AANLkTiksJsjSDJY61b7iNkJVvXgjP5NkV0g4fMOLV0AX@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2010/12/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Furthermore, it's underspecified: who's to say how many dimensions of
>>> the array are supposed to get sliced off?  There's no reasonable place
>>> to extend this syntax to specify that.  It will also be inconsistent
>>> for "foreach scalar in array" to iterate element-by-element no matter
>>> how many dimensions array has, while "foreach array in array" does
>>> something different from that.
>
>> it reduce just one dimension. Now I expect, and I think so it is
>> correct, so user knows a used dimension. Just doesn't know a data. So
>> user can to decide and fill correct type. The design strictly remove
>> any U.I. from design. So using a incorect type is bug.
>
> In other words, your proposal is error-prone to use, restricted in what
> it can do, and incapable of being extended later without breaking
> things.  If there is some redeeming social value to set against those
> problems, I'm not seeing it.
>
> What I think we should have is
>
>        FOREACH scalar-variable IN ARRAY array-expression
>
> which iterates element by element regardless of how many dimensions the
> array has.  Then there should be some other syntax for iterating over
> slices, and we should give some thought to being able to specify how
> "deep" the slice is.  I can definitely think of use cases for pulling
> off either 1 dimension at a time (so you get vectors) or N-1 dimensions
> at a time, and it's not out of the realm of reason to want intermediate
> cases.
>
> Maybe
>
>        FOR_EACH scalar-variable IN ARRAY array-expression
>
>        FOR_SLICE array-variable [DEPTH n] IN ARRAY array-expression
>
> Or I guess you could use the same leading keyword if you make the depth
> specification mandatory for the slice case:
>
>        FOREACH scalar-variable IN ARRAY array-expression
>
>        FOREACH array-variable SLICE n IN ARRAY array-expression
>
> That might be a better idea since it avoids the inevitable argument over
> whether the default slice depth should be 1 dimension or N-1 dimensions.

another way:

FOREACH scalar IN ARRAY arr_exp DIMS in dim_var

dim_var being int[], or possibly text, of length #dimensions, giving
per dimesion index.

I like this because it would fit well with alternate form of unnest,
should it ever be written:

create function unnest(anyarray, dims out int[], elem out anyelement)
returns setof...

SLICE notation is still good though, and it's probably faster since
you have less work to do in iteration step? It's certainly easier,
but very plpgsql specific.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-17 17:08:04 Re: bug in SignalSomeChildren
Previous Message Greg Sabino Mullane 2010-12-17 16:45:08 Re: clang and LLVM