Re: final patch - plpgsql: for-in-array

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: final patch - plpgsql: for-in-array
Date: 2010-11-18 19:34:37
Message-ID: AANLkTi=cwb-z_YbP61a-cAeGzY3aqqkKbbgPK4XLsiba@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/11/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> this note was a different -only  a few people use FOR IN SELECT UNNEST
>> for iteration over array. So from Robert's question (what is important
>> for current code?) perspective the more significant is access to
>> individual fields via subscripts. For example:
>
>> for i in 1..10000 loop
>>   s := s + A[i];
>> end loop
>
>> is slow, when high limit of array is some bigger number > 1000.
>
> True, but inventing new FOR syntax isn't going to help people who are
> used to doing that.

sure - I don't try it. Any change of this mean significant plpgsql's
refactoring and significant increasing the size and complexity of
code. More there can be still some overhead, because subscript can be
expression. And in almost all cases people dislike to write
subscripts.

>
>                        regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-11-18 19:37:40 Re: Per-column collation
Previous Message Pavel Stehule 2010-11-18 19:32:00 Re: final patch - plpgsql: for-in-array