"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> 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?
Well, it's a behavioral cha
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
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I suspect we have a significant incompatibility with PLSQL in this area.
Ugh. Google seems to confirm your thought that Oracle expects
FOR i IN REVERSE 1..10 LOOP
which is not the way we are doing it. Not sure
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I suspect we have a significant incompatibility with PLSQL in this area.
Ugh. Google seems to confirm your thought that Oracle expects
> FOR i IN REVERSE 1..10 LOOP
which is not the way we are doing it. Not sure if it's worth trying to
fix this -
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 l
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 wil
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 intege
