Re: plpgsql.warn_shadow
От | Joel Jacobson |
---|---|
Тема | Re: plpgsql.warn_shadow |
Дата | |
Msg-id | CAASwCXdxW46+vT9VUsM633hr6jM_Y_Zu+mRViAu98tXzzNVVog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql.warn_shadow (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: plpgsql.warn_shadow
|
Список | pgsql-hackers |
On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > You're reasoning from a false premise: it's *not* necessarily an error. When wouldn't it be an error? Can you give a real-life example of when it would be a good idea to use the same name of an input parameter as a declared variable? Isn't this almost exactly the same situation as we had in 9.0? "PL/pgSQL now throws an error if a variable name conflicts with a column name used in a query (Tom Lane)" (http://www.postgresql.org/docs/9.1/static/release-9-0.html) Making variables in conflict with column names an error was a very good thing. Making variables in conflict with in/out parameters would also be a very good thing, by default. And for the ones who are unable to fix their code, let them turn the error off by a setting. Maybe we don't even need a new setting, maybe the existing plpgsql.variable_conflict could be reused?
В списке pgsql-hackers по дате отправления: