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

Поиск
Список
Период
Сортировка
От Dmitriy Igrishin
Тема Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Дата
Msg-id AANLkTikUVrf4Zv+hWccKb6TohLpisBPDmtHz3CTCsM=m@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers


2010/12/17 Merlin Moncure <mmoncure@gmail.com>
On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2010/12/17 Tom Lane <tgl@sss.pgh.pa.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



--
// Dmitriy.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Следующее
От: Itagaki Takahiro
Дата:
Сообщение: Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)