From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Takahiro Itagaki <itagaki(dot)takahiro(at)gmail(dot)com> |
Subject: | Re: updated patch for foreach stmt |
Date: | 2011-02-16 04:45:19 |
Message-ID: | AANLkTi=bNG9wb35oPzkmA1zP_KOjGRYQ7p-NKoRJz-GE@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/2/16 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 02/15/2011 08:59 PM, Robert Haas wrote:
>>> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
>>> cheap future-proofing to me. YMMV.
>
>> If this is the syntax that makes you do things like:
>> FOREACH foo IN ARRAY ARRAY[1,2,3]
>> I have to say I find that pretty darn ugly still.
>
> Yeah, that was the argument against requiring ARRAY. So it comes down
> to whether you think we need future-proofing here. I can't immediately
> see any reason for us to need a keyword right there, but ...
the combination of two keywords isn't nice, but we can ensure so
result of expression will has a requested type. It's more verbose,
it's more secure. We can to check a allowed keywords like SCALING in
compile time, we can use a more keywords - A hash type can need a
separation between KEY and VALUE - so any keyword there enables a
higher possibilities in future. We can do it without a auxiliary
keyword too, but parser will be more complex.
Regards
Pavel Stehule
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-02-16 05:59:43 | Re: Change pg_last_xlog_receive_location not to move backwards |
Previous Message | Tom Lane | 2011-02-16 04:29:39 | Re: updated patch for foreach stmt |