Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: plpgsql.warn_shadow
Дата
Msg-id 6865.1393945614@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: plpgsql.warn_shadow  (Joel Jacobson <joel@trustly.com>)
Ответы Re: plpgsql.warn_shadow  (Joel Jacobson <joel@trustly.com>)
Список pgsql-hackers
Joel Jacobson <joel@trustly.com> writes:
> 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.

> 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)"

No; the reason why the old behavior was problematic was precisely that
it failed to conform to normal block-structured language design rules
(namely that the most closely nested definition should win).  If it
had been like that to start with we'd probably have just left it that
way.  The complexity of behavior that you see there today is there to
help people with debugging issues created by that change of behavior.

While I don't necessarily have an objection to creating a way to help
debug variable-name-shadowing issues, the idea that they're broken and
we can just start throwing errors is *wrong*.  The whole point of block
structure in a language is that a block of code can be understood
independently of what surrounds it.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: Custom Scan APIs (Re: Custom Plan node)
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Securing "make check" (CVE-2014-0067)