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