From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: final patch - plpgsql: for-in-array |
Date: | 2010-11-18 15:24:34 |
Message-ID: | AANLkTi=Fp=ub_0J8n--hpuBft6mE9JVcHcj_Zc9pgokK@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>>> i will start the review of this one... but before that sorry for
>>> suggesting this a bit later but about using UNNEST as part of the
>>> sintax?
>
>> Does for-in-array do what unnset does?
>
> Yes, which begs the question of why bother at all. AFAICS this patch
> simply allows you to replace
>
> for x in select unnest(array_value) loop
>
> with
>
> for x in unnest array_value loop
>
> (plus or minus a parenthesis or so). I do not think we need to add a
> bunch of code and create even more syntactic ambiguity (FOR loops are
> already on the hairy edge of unparsability) to save people from writing
> "select".
Pavel's performance argument is imnsho valid. arrays at present are
the best way to pass data around functions and any optimizations here
are very welcome. Given that, is there any way to mitigate your
concerns on the syntax side?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-18 15:24:44 | Re: unlogged tables |
Previous Message | Alvaro Herrera | 2010-11-18 15:07:49 | Re: duplicate connection failure messages |