On Thu, May 18, 2006 at 08:40:04PM -0400, Douglas McNaught wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
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
Ühel kenal päeval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
Something that's always bugged me is how horribly variables are handled
in plpgsql, namely that if you have a variable and a field with the same
name it can be extremely difficult to keep them seperated. Perhaps := vs
= might
On Fri, May 19, 2006 at 09:57:29PM +0300, Hannu Krosing wrote:
??hel kenal p??eval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
Something that's always bugged me is how horribly variables are handled
in plpgsql, namely that if you have a variable and a field with the same
name it can
Ühel kenal päeval, R, 2006-05-19 kell 14:39, kirjutas Jim C. Nasby:
On Fri, May 19, 2006 at 09:57:29PM +0300, Hannu Krosing wrote:
??hel kenal p??eval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
Something that's always bugged me is how horribly variables are handled
in plpgsql,
On Fri, May 19, 2006 at 11:03:21PM +0300, Hannu Krosing wrote:
A less disruptive change would be to have some predefined record where
all local variables belong to, perhaps called 'local' or '_local_' :) so
one could access both input parameter inp_orderdate and declared
variable var_orderdate
Ühel kenal päeval, R, 2006-05-19 kell 16:12, kirjutas Jim C. Nasby:
On Fri, May 19, 2006 at 11:03:21PM +0300, Hannu Krosing wrote:
A less disruptive change would be to have some predefined record where
all local variables belong to, perhaps called 'local' or '_local_' :) so
one could access
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, R, 2006-05-19 kell 16:12, kirjutas Jim C. Nasby:
IIRC, Oracle handles this by allowing you to prefix variables with the
name of the function.
what happens if your function name is the same as some table name or
local record
Ühel kenal päeval, K, 2006-05-17 kell 20:17, kirjutas Jonah H. Harris:
On 5/17/06, Hannu Krosing [EMAIL PROTECTED] wrote:
Does ADA have both assignment and comparison as operators, or is
assignment a statement ?
Yes. Assignment is := and comparison is =
I meant to ask, if := is a
Josh Berkus wrote:
If you only care about Oracle to PostgreSQL (and who wouldn't?), then
it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
I agree with David here. We care about the ability to migrate PL/SQL --
PL/pgSQL. We do *not* care about the ability to migrate
* Jonah H. Harris:
On 5/17/06, Hannu Krosing [EMAIL PROTECTED] wrote:
Does ADA have both assignment and comparison as operators, or is
assignment a statement ?
Yes. Assignment is := and comparison is =
And its name is spelled Ada, not ADA, even though the language
itself is
Ühel kenal päeval, N, 2006-05-18 kell 09:28, kirjutas Albe Laurenz:
Josh Berkus wrote:
If you only care about Oracle to PostgreSQL (and who wouldn't?), then
it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
I agree with David here. We care about the ability to
Hannu Krosing wrote:
Can you do something like A (B := C) or IF (A:=B) THEN ... in
ADA ?
Er, that's Ada; ADA is the American Dental Association among other
things.
And no you certainly can't do it. Assignment is a statement, not an
expression, and this family of languages
Tom Lane wrote:
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
Mark Dilger schrob:
Tom Lane wrote:
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.
I disagree. If the scanner treated them the same, then
if i := 1
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
I disagree. If the scanner treated them the same,
Douglas McNaught wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Tom Lane wrote:
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.
I disagree. If the scanner
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
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
Andrew Dunstan [EMAIL PROTECTED] 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
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.
Albe Laurenz [EMAIL PROTECTED]
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
Andrew Dunstan [EMAIL PROTECTED] 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
On Tue, May 16, 2006 at 07:56:25PM -0700, David Wheeler wrote:
On May 16, 2006, at 19:52, Tom Lane wrote:
Distant ancestors aren't particularly relevant here. What plpgsql
tries
to be is a ripoff^H^H^H^H^H^Hsincere flattery of Oracle's PL/SQL. If
modifying the loop variable is
On Tue, May 16, 2006 at 07:56:25PM -0700, David Wheeler wrote:
If you only care about Oracle to PostgreSQL (and who wouldn't?), then
it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
Oh, and PL/SQL is a lot more powerful than plpgsql. See packages for one
thing...
--
Jim C.
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
Tom,
If you only care about Oracle to PostgreSQL (and who wouldn't?), then
it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
I agree with David here. We care about the ability to migrate PL/SQL --
PL/pgSQL. We do *not* care about the ability to migrate PL/pgSQL --
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
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
Ü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
On Wed, May 17, 2006 at 10:18:51AM -0700, Josh Berkus wrote:
Tom,
If you only care about Oracle to PostgreSQL (and who wouldn't?), then ?
it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
I agree with David here. We care about the ability to migrate PL/SQL --
Hannu Krosing wrote:
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
Ühel kenal päeval, K, 2006-05-17 kell 16:31, kirjutas Andrew Dunstan:
Hannu Krosing wrote:
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
Hannu Krosing said:
* = is used in CONST declaration in PASCAL, whereas pl/pgSQL
documents := (i.e. ASSIGNMENT) for const declaration
Pascal is not the direct ancestor of PL/SQL, Ada is, and it uses := for
constant initialisation.
cheers
andrew
---(end of
On 5/17/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Pascal is not the direct ancestor of PL/SQL, Ada is, and it uses := for
constant initialisation.
True dat. Almost all PL/SQL components come from ADA.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation
Ühel kenal päeval, K, 2006-05-17 kell 17:51, kirjutas Jonah H. Harris:
On 5/17/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Pascal is not the direct ancestor of PL/SQL, Ada is, and it uses := for
constant initialisation.
Does ADA have both assignment and comparison as operators, or is
On 5/17/06, Hannu Krosing [EMAIL PROTECTED] wrote:
Does ADA have both assignment and comparison as operators, or is
assignment a statement ?
Yes. Assignment is := and comparison is =
Maybe we need just pl/ADA ;) ?
Wouldn't hurt :)
--
Jonah H. Harris, Software Architect | phone:
Andrew Dunstan [EMAIL PROTECTED] writes:
Even C doesn't use the same operator for assignment and comparison.
However, SQL *does*, so it seems to me that plsql is gratuitously
inconsistent with its larger environment.
regards, tom lane
---(end of
On 5/17/06, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
(No, I'm not particularly in favor of the BY feature mentioned upthread,
either.)
mmm... and why is that?
Essentially because it's not in the upstream language. Oracle could
come out with the same
Hellow PostgreSQL hackers,
Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
function?
try=# CREATE OR REPLACE FUNCTION inc_by_two(
try(#upfrom int,
try(#upto int
try(# ) RETURNS SETOF INT AS $$
try$# BEGIN
try$# FOR i IN upfrom..upto LOOP
try$#
David Wheeler wrote:
Hellow PostgreSQL hackers,
Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
function?
try=# CREATE OR REPLACE FUNCTION inc_by_two(
try(#upfrom int,
try(#upto int
try(# ) RETURNS SETOF INT AS $$
try$# BEGIN
try$# FOR i IN upfrom..upto
David Wheeler wrote:
Hellow PostgreSQL hackers,
Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
function?
try=# CREATE OR REPLACE FUNCTION inc_by_two(
try(#upfrom int,
try(#upto int
try(# ) RETURNS SETOF INT AS $$
try$# BEGIN
try$# FOR i IN
On May 16, 2006, at 16:30, Andrew Dunstan 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.
I agree, but I must say that it's incredibly useful to be able to
increment by two as I go through a
Mark Dilger wrote:
David Wheeler wrote:
Hellow PostgreSQL hackers,
Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
function?
try=# CREATE OR REPLACE FUNCTION inc_by_two(
try(#upfrom int,
try(#upto int
try(# ) RETURNS SETOF INT AS $$
try$# BEGIN
try$# FOR i
On May 16, 2006, at 16:42, Mark Dilger wrote:
So I don't know why it works for you. I wrote the following, and
it also
increments the variable:
CREATE OR REPLACE FUNCTION weird () RETURNS SETOF INT AS $$
DECLARE
i integer;
BEGIN
i := 0;
return next i;
i = i + 1;
return
On May 16, 2006, at 16:53, Mark Dilger wrote:
Sorry, I meant to say that it should only be a no-op according to
the language
specification, as I understand it. The fact that it works suggests
to me that
the implementation of PL/pgsql has been modified (or broken?).
Whether the
change is
David Wheeler wrote:
On May 16, 2006, at 16:53, Mark Dilger wrote:
Sorry, I meant to say that it should only be a no-op according to the
language
specification, as I understand it. The fact that it works suggests
to me that
the implementation of PL/pgsql has been modified (or broken?).
On May 16, 2006, at 17:02, Mark Dilger wrote:
It seems this has been answered before, by Tom Lane:
http://archives.postgresql.org/pgsql-novice/2006-04/msg00138.php
Ah, cool, then it *is* known.
Thanks,
David
---(end of broadcast)---
TIP 2:
On 5/16/06, David Wheeler [EMAIL PROTECTED] wrote:
On May 16, 2006, at 16:30, Andrew Dunstan 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.
I agree, but I must say that it's incredibly useful to
On May 16, 2006, at 17:51, Jaime Casanova wrote:
i have posted a patch to add a BY clause to the for statement (integer
version), with the BY clause you can specify an increment value...
it's in the unapplied patches list waiting for review...
Andrew Dunstan [EMAIL PROTECTED] writes:
It ought to be illegal to modify the loop control variable anyway,
IMNSHO - it certainly is in Ada, the distant antecedent of pl/pgsql.
Distant ancestors aren't particularly relevant here. What plpgsql tries
to be is a ripoff^H^H^H^H^H^Hsincere
On May 16, 2006, at 19:52, Tom Lane wrote:
Distant ancestors aren't particularly relevant here. What plpgsql
tries
to be is a ripoff^H^H^H^H^H^Hsincere flattery of Oracle's PL/SQL. If
modifying the loop variable is disallowed in PL/SQL, I'm all for
disallowing it in plpgsql, otherwise not.
David Wheeler [EMAIL PROTECTED] writes:
Even if PL/SQL disallows it, why would you not allow it in PL/pgSQL?
Um ... design sanity and consistency, maybe? Not that I think PL/SQL
is any paragon of those virtues, but surely we'll invent any feature
we feel like whether it's sane or not is not a
On May 16, 2006, at 20:51, Tom Lane wrote:
Um ... design sanity and consistency, maybe? Not that I think PL/SQL
is any paragon of those virtues, but surely we'll invent any feature
we feel like whether it's sane or not is not a recipe for a
maintainable language.
Yes, sanity is important, I
(No, I'm not particularly in favor of the BY feature mentioned upthread,
either.)
regards, tom lane
mmm... and why is that? i mean, many languages have some way to
increment the for variable by different values... call it STEP, BY or
even i+=number
--
regards,
Jaime Casanova [EMAIL PROTECTED] writes:
(No, I'm not particularly in favor of the BY feature mentioned upthread,
either.)
mmm... and why is that?
Essentially because it's not in the upstream language. Oracle could
come out with the same feature next week, only they use STEP or some
other
55 matches
Mail list logo
