On Jan20, 2014, at 14:05 , Marko Tiikkaja <ma...@joh.to> wrote: > On 1/20/14 1:55 PM, Robert Haas wrote: >> On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja <ma...@joh.to> wrote: >>> What's so hard about plpgsql.warnings='all'? Or if the fact that it's a >>> list is your concern, I'm not going to oppose to making it a boolean. >> >> Sure, that'd be fine. What I don't want is to have to start each function >> with: >> >> #option warn_this >> #option warn_that >> #option warn_theotherthing >> #option warn_somethingelse >> #option warn_yetanotherthing >> #option warn_whatdoesthisdoagain > > Right. Completely agreed. The only reason I had them in the patch is to > have the > ability to turn *off* a specific warning for a particular function. But even > that's of a bit dubious a value.
I think as long as there's an easy way to avoid a warning - in the case of warn_shadow e.g. by renaming the shadowing variable - there's no real requirement to be able to disable the warning on a per-function basis. And if there isn't a simple way to avoid a particular warning then we ought not warn about it anyway, I guess, because that would indicate that there are genuine reasons for doing whatever it is the warning complains about. 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
