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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?)
Дата
Msg-id AANLkTincq_1fnzmcJ1XYGAgnPyBk5=8X7tsPthcRLkiH@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?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> We would need an extra keyword if there were some third kind of
> iteration that was fundamentally different from either of these, but
> like I said, I don't see a plausible candidate.  So right at the moment,
> I'm leaning to the position that we could do without the ARRAY keyword
> in FOREACH.  If we do think of something else that could need its own
> keyword there, it's arguably going to be different enough that a
> different leading keyword would be a better idea anyhow.
>

Maybe I propage a higher verbosity than is necessary, but it descrease
a risk so code will do some unexpected work. With ARRAY keyword we can
verify so result of expression is really a array. Next advantage is a
clean implementation now and in future. Without a auxilary keyword is
necessary to wait on execution time. So now, when we have full control
over syntax, we can protect self before "FOR" statement
implementation's complexity.

Personally - syntax without ARRAY keyword isn't significant problem
for me. Just I think so using it wisely.

Second semi argument for using ARRAY keyword is a verbosity of
PL/pgSQL. So from this perspective a ARRAY should be minimally
optional and ensure, so expr result will be really a array. But with a
optional ARRAY keyword we leaving a simple enhancing in future (on
parser level).

Pavel


>                        regards, tom lane
>


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Why don't we accept exponential format for integers?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: unlogged tables vs. GIST