"Pavel Stehule" <email@example.com> writes:
On 10/11/2007, Marko Kreen 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 $$
foobar := 'ok';
$$ 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;
declare foo record;
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