Re: ambiguous local variable name in 9.0 proc - Mailing list pgsql-sql

From Tom Lane
Subject Re: ambiguous local variable name in 9.0 proc
Date
Msg-id 3450.1316649650@sss.pgh.pa.us
Whole thread Raw
In response to Re: ambiguous local variable name in 9.0 proc  ("David Johnston" <polobo@yahoo.com>)
List pgsql-sql
"David Johnston" <polobo@yahoo.com> writes:
> On Behalf Of Samuel Gendler
> I'm happy to modify the proc definition, except that I am unsure how to do
> so other than to rename the variable, which is my least favourite way to do
> that.  I'd far rather qualify the name somehow, so that it knows that I am
> refering to a local variable, if at all possible.  Suggestions?
> Not tested but I think all local variables are implicitly scoped to the
> function name so you should be able to do the following:
> WHERE reporting_mgmt.aggregate_timescales_impl.tbl_schema = e.tbl_schema

More accurately: you can qualify a local variable's name with the label
attached to the block in which it's declared; or with the function's
name if the variable is a function parameter.  See the fine manual:

http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html

> I believe there is some way to define the function so that it does not throw
> that particular error; it would be up to you make sure that the ambiguity is
> being resolved correctly (which it should in this particular case).

Yes, see variable_conflict in
http://www.postgresql.org/docs/9.0/static/plpgsql-implementation.html

I wouldn't really recommend turning off the conflict detection, though.
We put it in because of the number of hours people had wasted on
unrecognized conflicts.
        regards, tom lane


pgsql-sql by date:

Previous
From: Samuel Gendler
Date:
Subject: Re: ambiguous local variable name in 9.0 proc
Next
From: Amar Dhole
Date:
Subject: Re: handling duplicate row exception