Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: plpgsql.warn_shadow
Дата
Msg-id CAFj8pRAqzuLQ4w3SNXMcLNU0+OfXaDsR0+CO9w6_1BKR=ci=pQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Список pgsql-hackers



2014/1/15 Marko Tiikkaja <marko@joh.to>
On 1/15/14 11:20 AM, Pavel Stehule wrote:

2014/1/15 Marko Tiikkaja <marko@joh.to>
Hmm.  How about:

   plpgsql.warnings = 'all' # enable all warnings, defauls to the empty
list, i.e. no warnings
   plpgsql.warnings = 'shadow, unused' # enable just "shadow" and "unused"
warnings
   plpgsql.warnings_as_errors = on # defaults to off?

This interface is a lot more flexible and should address Jim's concerns as
well.


In this context is not clean if this option is related to plpgsql compile
warnings, plpgsql executor warnings or general warnings.

plpgsql.compile_warnings = "disabled", "enabled", "fatal"

I agree, it's better to include the word "compiler" in the GUC name. But do we really need WARNING, ERROR and FATAL levels though?  Would WARNING and ERROR not be enough?

I am not strong in level names - and it is my subjective opinion only (as not native speaker)

just

plpgsql.compile_warning=warning

or

plpgsql.compile_warning=error

looks little bit obscure (or as contradiction). More - "fatal" is used by gcc and some compilers as "stop on first error"

Regards

Pavel
 



Regards,
Marko Tiikkaja

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

Предыдущее
От: "Erik Rijkers"
Дата:
Сообщение: Re: nested hstore patch - FailedAssertion("!(value->array.nelems == 1)
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: ISN extension bug? (with patch)