Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: plpgsql.warn_shadow
Дата
Msg-id CA+U5nMKbMntpGR3dXv4Zj0pJKw6=tPvCj1=nYK-5GLW_3dE3rA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpgsql.warn_shadow  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers
On 3 February 2014 20:17, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hello
>
> I am not happy from "warnings_as_error"
>
> what about "stop_on_warning" instead?
>
> second question: should be these errors catchable or uncatchable?
>
> When I work on large project, where I had to use some error handler of
> "EXCEPTION WHEN OTHERS" I found very strange and not useful so all syntax
> errors was catched by this handler. Any debugging was terribly difficult and
> I had to write plpgsql_lint as solution.

The patch looks fine, apart from some non-guideline code formatting issues.

Having looked at gcc and clang, I have a proposal for naming/API

We just have two variables
 plpgsql.compile_warnings = 'list'    default = 'none' plpgsql.compile_errors = 'list'        default = 'none'

Only possible values in 9.4 are 'shadow', 'all', 'none'

If we can agree something quickly then we can commit this for 9.4

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: About the portal in postgres
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Archive recovery won't be completed on some situation.