Re: plpgsql.warn_shadow

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



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

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"

I was talking about postgres error levels above.  If we define "fatal" to mean ERROR here, I'm quite certain that will confuse people.  How's:

  plpgsql.compiler_warning_severity = 'error' # disable, warning, error matching PG error severity levels ("disable" disables, obviously)

I don't think it is correct - "warning" is "severity" - it is about handling of warnings. It is little bit fuzzy, and I have no good idea now :(
 
  plpgsql.compiler_warnings = 'list, of, warnings'

is not it useless? I don't think it is generally usable. Now plpgsql compiler doesn't raise any warning and better to raise warnings only when the warning can be really important.

Regards

Pavel
 


Regards,
Marko Tiikkaja

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

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: plpgsql.warn_shadow
Следующее
От: Mel Gorman
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance