Re: PL/pgSQL: possible parsing or documentation bug?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Albert REINER" <areiner(at)tph(dot)tuwien(dot)ac(dot)at>
Cc: PostgreSQL-SQL <pgsql-sql(at)postgresql(dot)org>
Subject: Re: PL/pgSQL: possible parsing or documentation bug?
Date: 2001-02-03 22:15:51
Message-ID: 4317.981238551@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"Albert REINER" <areiner(at)tph(dot)tuwien(dot)ac(dot)at> writes:
> create Function IdOfPossiblyNewAuthor(text) returns int4 as '
> declare
> id int4;
> begin
> select id into id from author where name = $1;
> raise notice ''ID found: %'', id;
> if id is null then
> insert into author (name) values ($1);
> select currval(''author_id_seq'') into id;
> raise debug ''Author inserted. ID: %'', id;
> end if;
> return id;
> end;
> ' language 'plpgsql' with (IsCachable);

> Logically it is clear which "id" should be parsed as the variable,
> which as author.id,

No, it is not so clear. Consider the following:

declare
x int4;
y int4;
begin
x := ...;
select x + f1 into y from tab1 where ...;

The intent here is clearly to find a value tab1.f1 in tab1 and then
add the local variable x to form a value for the local variable y.

In general plpgsql will try to match an unqualified name to a variable
before it will consider whether it might be a field name. If you don't
want that, qualify the field name:

select author.id into id from author where name = $1;

Feel free to submit documentation updates to make this clearer...

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tod McQuillin 2001-02-04 07:59:03 Re: Bug with rules in 7.0.3?
Previous Message Hubert Palme 2001-02-03 20:46:08 parse error in create index