Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> 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 from 10 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 section of the docs relating to porting
from PLSQL.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
