Re: plpgsql.warn_shadow

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



2014/1/15 Marko Tiikkaja <marko@joh.to>
On 1/15/14 7:07 AM, Florian Pflug wrote:
On Jan15, 2014, at 01:34 , Marko Tiikkaja <marko@joh.to> wrote:
It's me again, trying to find a solution to the most common mistakes I make.  This time it's accidental shadowing of variables, especially input variables.  I've wasted several hours banging my head against the wall while shouting "HOW CAN THIS VARIABLE ALWAYS BE NULL?".  I can't believe I'm the only one.  To give you a rough idea on how it works:

I like this, but think that the option should be just called plpgsql.warnings or plpgsql.warn_on and accept a list of warnings to enable.

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"

Regards

Pavel
 


Regards,
Marko Tiikkaja



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql.consistent_into
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: plpgsql.warn_shadow