2014-01-26 Florian Pflug <f...@phlo.org> > On Jan26, 2014, at 10:19 , Simon Riggs <si...@2ndquadrant.com> wrote: > > Also, having > > plpgsql.warnings_as_errors = off (default) | on > > makes sense and should be included in 9.4 > > I still think this is a bad idea, for the same reasons I don't like > consistent_into (discussed in a separate thread). > > But these objections would go away if restricted this to function > creation time only. So even with warnings_as_errors=on, you > could still *call* a function that produces a warning, but not > *create* one. >
+1 behave - and please, better name Regards Pavel > > We could then integrate this with check_function_bodies, i.e. add a > third possible value "error_on_warnings" to that GUC, instead of > having a separate GUC for this. > > > Putting this and all future options as keywords seems like a poor > > choice. Indeed, the # syntax proposed isn't even fully described on > > list here, nor are examples given in tests. My feeling is that nobody > > even knows that is being proposed and would likely cause more > > discussion if they did. So I wish to push back the # syntax to a later > > release when it has had more discussion. It would be good if you could > > lead that discussion in later releases. > > +1 > > 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 >
