On Jan15, 2014, at 13:08 , Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2014/1/15 Florian Pflug <f...@phlo.org> >> On Jan15, 2014, at 11:20 , Pavel Stehule <pavel.steh...@gmail.com> wrote: >> > 2014/1/15 Marko Tiikkaja <ma...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
