Re: final patch - plpgsql: for-in-array - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: final patch - plpgsql: for-in-array
Date
Msg-id AANLkTi=Fp=ub_0J8n--hpuBft6mE9JVcHcj_Zc9pgokK@mail.gmail.com
Whole thread Raw
In response to Re: final patch - plpgsql: for-in-array  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: final patch - plpgsql: for-in-array
Re: final patch - plpgsql: for-in-array
List pgsql-hackers
On Thu, Nov 18, 2010 at 12:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova <jaime@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: duplicate connection failure messages
Next
From: Robert Haas
Date:
Subject: Re: unlogged tables