Tom Lane wrote:
>> It ought to be illegal to modify the loop control variable anyway,
>> IMNSHO - it certainly is in Ada, the distant antecedent of pl/pgsql.
>
> If modifying the loop variable is disallowed in PL/SQL, I'm all for
> disallowing it in plpgsql, otherwise not. Anyone have a
> recent copy of Oracle to try it on?

I tried this on Oracle 10.2.0.2.0 (which is the most recent version):

SET SERVEROUTPUT ON
BEGIN
FOR i IN 1..10 LOOP
i := i + 1;
DBMS_OUTPUT.PUT_LINE(i);
END LOOP;
END;
/
i := i + 1;
*
ERROR at line 3:
ORA-06550: line 3, column 7:
PLS-00363: expression 'I' cannot be used as an assignment target
ORA-06550: line 3, column 7:
PL/SQL: Statement ignored

And the documentation also explicitly states that it is not allowed.

By the way, PL/SQL screams if you want to do an assignment with '='.
But I guess that the current behaviour of PL/pgSQL should not reflect
that to maintain backward compatibility, right?

Yours,
Laurenz Albe

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Albe Laurenz said:
> Tom Lane wrote:
>>> It ought to be illegal to modify the loop control variable anyway,
>>> IMNSHO - it certainly is in Ada, the distant antecedent of pl/pgsql.
>>
>> If modifying the loop variable is disallowed in PL/SQL, I'm all for
>> disallowing it in plpgsql, otherwise not. Anyone have a
>> recent copy of Oracle to try it on?
>
> I tried this on Oracle 10.2.0.2.0 (which is the most recent version):
>
> SET SERVEROUTPUT ON
> BEGIN
> FOR i IN 1..10 LOOP
> i := i + 1;
> DBMS_OUTPUT.PUT_LINE(i);
> END LOOP;
> END;
> /
> i := i + 1;
> *
> ERROR at line 3:
> ORA-06550: line 3, column 7:
> PLS-00363: expression 'I' cannot be used as an assignment target
> ORA-06550: line 3, column 7:
> PL/SQL: Statement ignored
>
> And the documentation also explicitly states that it is not allowed.
>

So should we if it can be done conveniently. That might be a big IF - IIRC
many Pascal compilers ignore the similar language rule because implementing
it is a pain in the neck.


> By the way, PL/SQL screams if you want to do an assignment with '='.
> But I guess that the current behaviour of PL/pgSQL should not reflect
> that to maintain backward compatibility, right?
>

I think it should. The current behaviour is undocumented and more than icky.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Andrew Dunstan" <andrew@dunslane.net> writes:
> Albe Laurenz said:
>> ERROR at line 3:
>> ORA-06550: line 3, column 7:
>> PLS-00363: expression 'I' cannot be used as an assignment target
>> ORA-06550: line 3, column 7:
>> PL/SQL: Statement ignored
>>
>> And the documentation also explicitly states that it is not allowed.

> So should we if it can be done conveniently. That might be a big IF - IIRC
> many Pascal compilers ignore the similar language rule because implementing
> it is a pain in the neck.

Since we already have the notion of a "const" variable in plpgsql,
I think it might work to just mark the loop variable as const.

>> By the way, PL/SQL screams if you want to do an assignment with '='.
>> But I guess that the current behaviour of PL/pgSQL should not reflect
>> that to maintain backward compatibility, right?

> I think it should. The current behaviour is undocumented and more than icky.

The lack of documentation is easily fixed ;-). I don't think this is
icky enough to justify breaking all the existing functions we'd
undoubtedly break if we changed it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:
>>> By the way, PL/SQL screams if you want to do an assignment with '='.
>>> But I guess that the current behaviour of PL/pgSQL should not reflect
>>> that to maintain backward compatibility, right?
>>>
>
>
>> I think it should. The current behaviour is undocumented and more than icky.
>>
>
> The lack of documentation is easily fixed ;-). I don't think this is
> icky enough to justify breaking all the existing functions we'd
> undoubtedly break if we changed it.
>
>


We have tightened behaviour in ways much harder to fix in the past, e.g.
actually following UTF8 rules. Fixing breakage in this case would be
pretty trivial, and nobody has any real right to expect the current
behaviour to work.

But I won't be surprised to be in a minority on this ....

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

""Albe Laurenz"" <all@adv.magwien.gv.at>
> Tom Lane wrote:
....
> > If modifying the loop variable is disallowed in PL/SQL, I'm all for
> > disallowing it in plpgsql, otherwise not. Anyone have a
> > recent copy of Oracle to try it on?
>
> I tried this on Oracle 10.2.0.2.0 (which is the most recent version):
>
> SET SERVEROUTPUT ON
> BEGIN
> FOR i IN 1..10 LOOP
> i := i + 1;
> DBMS_OUTPUT.PUT_LINE(i);
> END LOOP;
> END;
> /
> i := i + 1;
> *
> ERROR at line 3:
> ORA-06550: line 3, column 7:
> PLS-00363: expression 'I' cannot be used as an assignment target
> ORA-06550: line 3, column 7:
> PL/SQL: Statement ignored
>
> And the documentation also explicitly states that it is not allowed.
>
> By the way, PL/SQL screams if you want to do an assignment with '='.
> But I guess that the current behaviour of PL/pgSQL should not reflect
> that to maintain backward compatibility, right?
>

I think Oracle's syntax and behaviour are better.
As for this feature, breaking the backward compatibility is acceptable.

Regards,
William ZHANG

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> The lack of documentation is easily fixed ;-). I don't think this is
>> icky enough to justify breaking all the existing functions we'd
>> undoubtedly break if we changed it.

> We have tightened behaviour in ways much harder to fix in the past, e.g.
> actually following UTF8 rules.

True, but there were clear benefits from doing so. Disallowing "="
assignment in plpgsql wouldn't buy anything, just break programs.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Wed, May 17, 2006 at 10:11:39AM -0400, Tom Lane wrote:
> The lack of documentation is easily fixed ;-). I don't think this is
> icky enough to justify breaking all the existing functions we'd
> undoubtedly break if we changed it.

I thought the suggestion was to complain loudly (presumably during
CREATE FUNCTION), but not throw an error.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom,

> True, but there were clear benefits from doing so. Disallowing "="
> assignment in plpgsql wouldn't buy anything, just break programs.

But it's already disallowed in most places. The i = i + 1 seems to be an
exception.

So what happens to "i" if I do:

IF i = i + 1 THEN ....

does "i" increment? If so, isn't that a bug?

I don't think too many people are using that functionality intentionally; I
probably write more PL/pgSQL than anyone and would regard any assignment
without ":=" as a bug.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Josh Berkus <josh@agliodbs.com> writes:
>> True, but there were clear benefits from doing so. Disallowing "="
>> assignment in plpgsql wouldn't buy anything, just break programs.

> But it's already disallowed in most places.

No it isn't. The plpgsql scanner treats := and = as *the same token*.
They can be interchanged freely. This has nothing to do with the case
of modifying a loop variable in particular.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Ühel kenal päeval, K, 2006-05-17 kell 10:22, kirjutas Josh Berkus:
> Tom,
>
> > True, but there were clear benefits from doing so. Disallowing "="
> > assignment in plpgsql wouldn't buy anything, just break programs.
>
> But it's already disallowed in most places. The i = i + 1 seems to be an
> exception.
>
> So what happens to "i" if I do:
>
> IF i = i + 1 THEN ....
>
> does "i" increment? If so, isn't that a bug?
>
> I don't think too many people are using that functionality intentionally; I
> probably write more PL/pgSQL than anyone and would regard any assignment
> without ":=" as a bug.

I do occasionally write some pl/pgSQL, and have at some points written a
lot of it. And most of it uses = instead of := , including all code
written during last 1.5 years.

Once I found out that = works for assignment, i completely stopped
using := .I have treated := as "deprecated" for some time already.

So allowing only := for assignment would make me very sad .

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend