Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Petr Jelinek
Тема Re: plpgsql.warn_shadow
Дата
Msg-id 532896D9.9050209@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: plpgsql.warn_shadow  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: plpgsql.warn_shadow  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers

On 18/03/14 13:43, Pavel Stehule wrote:
2014-03-18 13:23 GMT+01:00 Petr Jelinek <petr@2ndquadrant.com>

Agree that compile_errors dos not make sense, additional_errors and additional_warnings seems better, maybe plpgsql.extra_warnings and plpgsql.extra_errors?

extra* sounds better

Ok, so I took the liberty of rewriting the patch so that it uses plpgsql.extra_warnings and plpgsql.extra_errors configuration variables with possible values "none", "all" and "shadow" ("none" being the default).
Updated doc and regression tests to reflect the code changes, everything builds and tests pass just fine.

I did one small change (that I think was agreed anyway) from Marko's original patch in that warnings are only emitted during function creation, no runtime warnings and no warnings for inline (DO) plpgsql code either as I really don't think these optional warnings/errors during runtime are a good idea.

Note that the patch does not really handle the list of values as list, basically "all" and "shadow" are translated to true and proper handling of this is left to whoever will want to implement additional checks. I think this approach is fine as I don't see the need to build frameworks here and it was same in the original patch.
-- Petr Jelinek                  http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Вложения

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_archivecleanup bug
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Portability issues in shm_mq