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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Дата
Msg-id AANLkTiksJsjSDJY61b7iNkJVvXgjP5NkV0g4fMOLV0AX@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Dmitriy Igrishin <dmitigr@gmail.com>)
Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

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


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: bug in SignalSomeChildren