Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: plpgsql.warn_shadow
Дата
Msg-id CA+TgmobM8F2ZnZZz9ZTtDG6+31BZLkGBVXxikNxLz_8m-viRYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers
On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja <marko@joh.to> wrote:
> On 1/17/14 11:26 AM, Pavel Stehule wrote:
>>
>> After some thinking I don't think so this design is not good. It  changing
>> a working with exception (error) levels - and it is not consistent with
>> other PostgreSQL parts.
>>
>> A benefit is less than not clean configuration. Better to solve similar
>> issues via specialized plpgsql extensions or try to help me push
>> plpgsql_check_function to core. It can be a best holder for this and
>> similar checks.
>
>
> I see these as being two are different things.  There *is* a need for a
> full-blown static analyzer for PL/PgSQL, but I don't think it needs to be in
> core.  However, there seems to be a number of pitfalls we could warn the
> user about with little effort in core, and I think those are worth doing.

I don't want to be overly negative, but that sounds sort of like
you're saying that it's not worth having a good static analyzer in
core, but that you are in favor of having a bad one.

I personally tend to think a static analyzer is a better fit than
adding a whole laundry list of pragmas.  Most people won't remember to
turn them all on anyway, and those who do will find that it gets
pretty tedious after we have more than about two of them.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: What is happening on buildfarm member crake?
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [v9.4] row level security