2014/1/15 Marko Tiikkaja <ma...@joh.to> > On 1/15/14 2:27 PM, Pavel Stehule wrote: > >> 2014/1/15 Marko Tiikkaja <ma...@joh.to> >> >>> Yeah, me neither, it's just something that needs to be communicated very >>> clearly. So probably just a list plpgsql.warnings would be the most >>> appropriate then. >>> >>> >> I am thinking so the name is not good. Changing handling warnings is messy >> - minimally in Postgres, where warnings and errors are different >> creatures. >> >> what about >> >> plpgsql.enhanced_checks = (none | warning | error) >> > > You crammed several suggestions into one here: > > 1) You're advocating the ability to turn warnings into errors. This has > been met with some resistance. I think it's a useful feature, but I would > be happy with just having warnings available. > 2) This syntax doesn't allow the user to specify a list of warnings to > enable. Which might be fine, I guess. I imagine the normal approach would > be to turn all warnings on anyway, and possibly fine-tune with per-function > directives if some functions do dangerous things on purpose. > 3) You want to change the name to "enhanced_checks". I still think the > main feature is about displaying warnings to the user. I don't > particularly like this suggestion. >
You first should to say, what is warning and why it is only warning and not error. And why plpgsql warning processing should be different than general postgresql processing? My objection is against too general option. Every option shoudl to do one clean thing. Regards Pavel > > > Regards, > Marko Tiikkaja >
