On 7/14/07, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
