From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?) |
Date: | 2010-12-17 17:35:28 |
Message-ID: | AANLkTikLAUTme_xbuJE=DUp0VMap2z=OQrHu7Np8qs1_@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/12/17 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
>
> On 12/17/2010 12:15 PM, Pavel Stehule wrote:
>>
>> 2010/12/17 Itagaki Takahiro<itagaki(dot)takahiro(at)gmail(dot)com>:
>>>
>>> It should be not a main subject, but I remember there was a discussion
>>> that "IN ARRAY array-expression" looks redundant for a literal array:
>>>
>>> IN ARRAY ARRAY[1, 3, 5]
>>>
>>> Are there any improvement for the issue?
>>
>> yes. It know it. The reason for this is bigger space for possible
>> future features related to FOREACH loop.
>>
>
> So what you're saying is we need to allow ugliness now so we can have more
> ugliness in future? I don't find that a convincing argument. I share the
> dislike for this syntax.
can be strange from me, but it is. If we close a back door now, then
we have not a space after ten years. There can be possible loops over
records, maybe over other iterable data. With this design is important
one think. A keyword after K_IN must not be a reserved keyword.
I am expecting, so typical use case doesn't be a iteration over
constant array, but over variable
so mostly often you have to write
FOREACH var IN ARRAY second_var
LOOP
...
END LOOP
Regards
Pavel
>
> cheers
>
> andrew
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2010-12-17 17:58:45 | Re: proposal : cross-column stats |
Previous Message | Tom Lane | 2010-12-17 17:31:13 | Re: proposal: FOREACH-IN-ARRAY (probably for 9.2?) |