From: | Joel Jacobson <joel(at)trustly(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql.warn_shadow |
Date: | 2014-03-04 08:56:57 |
Message-ID: | CAASwCXdxW46+vT9VUsM633hr6jM_Y_Zu+mRViAu98tXzzNVVog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2014-03-04 09:30:25 | Re: jsonb and nested hstore |
Previous Message | Simon Riggs | 2014-03-04 08:48:39 | Re: Patch: show relation and tuple infos of a lock to acquire |