On Jan15, 2014, at 11:20 , Pavel Stehule <pavel.stehule@gmail.com> wrote: > 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"
This makes no sense to me - warnings can just as well be emitted during execution. Why would we distinguish the two? What would that accomplish?
When we talked about plpgsql compiler warnings, we talked about relative important warnings that means in almost all cases some design issue and is better to stop early.
Postgres warnings is absolutly different kind - usually has informative character - and usually you don't would to increment severity.
More we talking about warnings produced by plpgsql environment - and what I know - it has sense only for compiler.
Regards
Pavel
P.S. lot of functionality can be coveraged by plpgsql_check_function. It is pity so we have not it in upstream.
