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

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.

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.

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?

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

Reply via email to