On 7/14/07, Tom Lane <tgl@sss.pgh.pa.us> 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.
>
while i read this the day you posted it, i didn't have time to answer
until now...
my answer is: sorry, my bad... have to admit that the idea of
preventing zero in the BY doesn't cross my mind.
http://archives.postgresql.org/pgsql-hackers/2006-04/msg01100.php
i remember my original proposal include that negative values shouldn't
be allowed, i don't know where my way was corrupted... maybe because
for statement didn't make any effort to prevent things like:
FOR i IN 10..1 LOOP
> Another problem is that no check for overflow is done when incrementing
> the loop variable, which means that an infinite loop is possible if the
> step value is larger than the distance from the loop upper bound to
> INT_MAX --- the loop variable could overflow before it is seen to be
> greater than the upper bound, and after wrapping around to negative
> it's still less than the upper bound, so the loop continues to run.
>
mmm... yeah!
> I suggest throwing an error for zero or negative step value, and
> terminating the loop if the loop variable overflows.
>
http://archives.postgresql.org/pgsql-committers/2007-07/msg00142.php
at least the part that prevents overflow and probably the one that
reject zero in BY are clearly bugs and should be backpatched to 8.2,
aren't they?
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning." Richard Cook
