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

From: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:11:43
Message-ID: AANLkTikUVrf4Zv+hWccKb6TohLpisBPDmtHz3CTCsM=m@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/12/17 Merlin Moncure <mmoncure(at)gmail(dot)com>

> 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.
>
If dim_var contains length it is need to be renamed:
FOREACH scalar IN ARRAY arr_exp SIZES IN sizes_var.

>
> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
// Dmitriy.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-12-17 17:11:45 Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Previous Message Pavel Stehule 2010-12-17 17:10:17 Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)