On Jan15, 2014, at 13:08 , Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2014/1/15 Florian Pflug <fgp@phlo.org>
>> On Jan15, 2014, at 11:20 , Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> > 2014/1/15 Marko Tiikkaja <marko@joh.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
generalwarnings.
>> >
>> > 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?
Whatwould that accomplish?
>
> When we talked about plpgsql compiler warnings, we talked about relative important warnings that means in almost all
casessome 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
incrementseverity.
>
> 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
particularwarning is emitted during compilation or during execution it largely irrelevant, I think. For example, if we
calledthis compiler_warning, we'd couldn't add a warning which triggers when SELECT .. INTO ingores excessive rows.
best regards,
Florian Pflug