"David Johnston" <pol...@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 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql