Re: plpgsql: another new reserved word

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> On 10/11/2007, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>> I stumbled on another gotcha in 8.3's plpgsql:

> It's label for function's parameters.

But now that you mention it, that behavior is a little bit ugly.
I believe it's a pretty common practice to use a variable named
the same as the function to hold the eventual function result.
We've just broken that coding practice.

It's especially annoying because there isn't any obvious need
for it: in

create or replace function foobar() returns text as $$
declare
foobar text;
begin
foobar := 'ok';
return foobar;
end;
$$ language plpgsql;

there is no use of "foobar" in a place where a block label would
be syntactically legal, so it seems like we should be able to
keep the two types of name separate.

I think the reason for this may be that there are weird cases where
things *are* ambiguous. Consider

<< foo >>
declare bar int;
begin
...
declare foo record;
begin
foo.bar := 42;

Are we assigning to the outer block's variable bar, or to a field of the
inner block's variable foo?

The current plpgsql code seems to be designed to force a qualifier to be
interpreted as a block label if at all possible, even if there are
more-closely-nested alternative interpretations; so in the above example
it would assign to the outer variable bar. This seems a tad bogus
to me. Can anyone comment on how Oracle handles cases like this?

regards, tom lane