Re: plpgsql.warn_shadow

On Jan15, 2014, at 13:08 , Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2014/1/15 Florian Pflug <fgp(at)phlo(dot)org>
>> On Jan15, 2014, at 11:20 , Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> > 2014/1/15 Marko Tiikkaja <marko(at)joh(dot)to>
>> > 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.

The fact that it's named plpgsql.warnings already clearly documents that this only affects plpgsql. But whether a particular warning is emitted during compilation or during execution it largely irrelevant, I think. For example, if we called this compiler_warning, we'd couldn't add a warning which triggers when SELECT .. INTO ingores excessive rows.

best regards,
Florian Pflug