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 recor
Ü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 coul
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_orde
Ü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
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
Ü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
> = mi
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 modifyin
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 disa
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
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
>
>
Tom Lane wrote:
> Josh Berkus 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
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 dis
Ü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 abilit
* 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 cas
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 m
Ü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
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 s
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 o
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: 732.331
Ü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
a
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
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 broadc
Ü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.
> >>
>
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
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 -->
Ü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
Josh Berkus 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 interch
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 "
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 -->
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 duri
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 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
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 i
""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 ve
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.
"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
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.
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
> recen
"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
(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
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
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 n
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.
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 flat
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...
http://candle.pha.pa.us/mhonarc/patches/msg3.h
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 t
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: Do
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
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
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 ne
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$#
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 loop:
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
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 LOO
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$# RETUR
55 matches
Mail list logo
