To: "David Johnston" <polobo@yahoo.com>
cc: "'Samuel Gendler'" <sgendler@ideasculptor.com>, pgsql-sql@postgresql.org
Subject: Re: ambiguous local variable name in 9.0 proc 
In-reply-to: <00c301cc78b9$0ca38e30$25eaaa90$@yahoo.com> 
References: 
 <CAEV0TzB5GDuaG=7OOv_7m6OWagAkkUmkeh=1a62E46o4wKdtgg@mail.gmail.com>
	<00c301cc78b9$0ca38e30$25eaaa90$@yahoo.com>
Comments: In-reply-to "David Johnston" <polobo@yahoo.com>
	message dated "Wed, 21 Sep 2011 19:49:05 -0400"
Date: Wed, 21 Sep 2011 20:00:50 -0400
Message-ID: <3450.1316649650@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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