From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David Johnston" <polobo(at)yahoo(dot)com> |
Cc: | "'Samuel Gendler'" <sgendler(at)ideasculptor(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: ambiguous local variable name in 9.0 proc |
Date: | 2011-09-22 00:00:50 |
Message-ID: | 3450.1316649650@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"David Johnston" <polobo(at)yahoo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Asli Akarsakarya | 2011-09-22 06:04:50 | a spatial table's bounding box |
Previous Message | Samuel Gendler | 2011-09-21 23:55:28 | Re: ambiguous local variable name in 9.0 proc |