Re: plpgsql FOR loop doesn't guard against strange step values

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>   
>> Tom Lane wrote:
>>     
>>> I just noticed that when the BY option was added to plpgsql FOR
>>> loops, no real error checking was done.  If you specify a zero step
>>> value, you'll have an infinite loop.  If you specify a negative
>>> value, the loop variable will increment in the "wrong direction"
>>> until integer overflow occurs.  Neither of these behaviors seem
>>> desirable in the least.
>>>       
>
>   
>> That seems to be fairly normal proramming language behavior.
>>     
>
> Well, it's about what I'd expect from C or something at a similar level
> of (non) abstraction.  But I dislike the idea that plpgsql should have
> behavior as machine-dependent as that the number of iterations will
> depend on the value of INT_MIN.  Also, at the SQL level our usual policy
> is to throw errors for obvious programmer mistakes, and it's hard to
> argue that a zero or negative step isn't a programmer mistake.  Had we
> defined the stepping behavior differently (ie, make "BY -1" work like
> REVERSE) then there would be some sanity in allowing negative steps,
> but I don't see the sanity in it given the implemented behavior.
>   


I suspect we have a significant incompatibility with PLSQL in this area. 
The docs give this example:
 FOR i IN REVERSE 10..1 LOOP     -- some computations here END LOOP;

In PLSQL, as I understand it, (and certainly in its ancestor Ada) this loop will execute 0 times, not 10. To iterate
from10 down to 1 one would need to say:
 

 FOR i IN REVERSE 1..10 LOOP     -- some computations here END LOOP;

I'm not sure if this has been noticed before. It's actually quite unfortunate. At least it should be mentioned in the
sectionof the docs relating to porting from PLSQL.
 



cheers

andrew