"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> On 10/11/2007, Marko Kreen <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
