Re: ambiguous local variable name in 9.0 proc
От
Samuel Gendler
Тема
Re: ambiguous local variable name in 9.0 proc
Дата
Msg-id
CAEV0TzDNpTyOnEdHes3eFOv2Dcs_SHyoPymd=hTYH4dASyS7ug@mail.gmail.com
Ответ на
Re: ambiguous local variable name in 9.0 proc (David Johnston)
Список
Дерево обсуждения
ambiguous local variable name in 9.0 proc Samuel Gendler <sgendler@ideasculptor.com>
Re: ambiguous local variable name in 9.0 proc "David Johnston" <polobo@yahoo.com>
Re: ambiguous local variable name in 9.0 proc Tom Lane <tgl@sss.pgh.pa.us>
Re: ambiguous local variable name in 9.0 proc Samuel Gendler <sgendler@ideasculptor.com>
On Wed, Sep 21, 2011 at 4:49 PM, David Johnston <polobo@yahoo.com> wrote:
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
Yep. It is also possible to change the db behaviour globally or on a per-function basis
"To change this behavior on a system-wide basis, set the configuration parameter plpgsql.variable_conflict to one of error, use_variable, or use_column(where error is the factory default)."
You can also set the behavior on a function-by-function basis, by inserting one of these special commands at the start of the function text:
#variable_conflict error #variable_conflict use_variable
#variable_conflict use_column
Sorry for jumping straight a mailing list query. It was actually relatively easy to find in the docs. Now to figure out if the function name scoping trick works in 8.4 so that I can modify my procs prior to upgrading my db.
--sam
В списке pgsql-sql по дате отправления
