2010/11/24 Robert Haas <robertmhaas@gmail.com>:
> On Tue, Nov 23, 2010 at 8:56 PM, Cédric Villemain
> <cedric.villemain.debian@gmail.com> wrote:
>> 2010/11/23 Robert Haas <robertmhaas@gmail.com>:
>>> On Mon, Nov 22, 2010 at 11:55 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>> ok, I can only recapitulate so this feature was proposed cca two
>>>> months ago, and minimally Tom and maybe you did agreement - with
>>>> request on syntax - do you remember? I am little bit tired so this
>>>> agreement was changed when I spent my time with this.
>>>
>>> I went back and reread the thread I believe you're speaking about.
>>> The first post is here:
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg01945.php
>>
>> Here perhaps ? (or before)
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg01983.php
>
> Dang. You're right. I stand corrected.
>
Sorry, I though so you and Tom hasn't a problem with syntax
FOR-IN-ARRAY (what is a Kevin Grittner's proposal). So problematic is
just my original proposal FOR-IN-expr, but proposed feature isn't
rejected.
My proposal isn't really genial - is true so first my motivation was
to replace a pattern array_lower(var,1)..array_upper(var,1). It's
relative simple in ADA, statement FOR is defined over range type, and
relative impossible in PL/pgSQL, where range type doesn't exists. Some
special construct in PL/pgSQL can to solve iteration over array
significantly better and simpler then any other solution - this really
must not be syntax FOR-IN-ARRAY - and with any next test and next code
checking I am more sure:
why:
* there is clean indicia so developer wants to process all items in array
* there isn't random access to array
* is possibility for a reuse varlena types stored in array without a
temporal copy
I am sorry, so I didn't speaking about these facts ear
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>