Hello I am not happy from "warnings_as_error"
what about "stop_on_warning" instead? second question: should be these errors catchable or uncatchable? When I work on large project, where I had to use some error handler of "EXCEPTION WHEN OTHERS" I found very strange and not useful so all syntax errors was catched by this handler. Any debugging was terribly difficult and I had to write plpgsql_lint as solution. Regards Pavel 2014-02-03 Marko Tiikkaja <ma...@joh.to>: > Hi everyone, > > Here's a new version of the patch. Added new tests and docs and changed > the GUCs per discussion. > > plpgsql.warnings_as_errors only affects compilation at CREATE FUNCTION > time: > > =# set plpgsql.warnings to 'all'; > SET > =#* set plpgsql.warnings_as_errors to true; > SET > =#* select foof(1); -- compiled since it's the first call in this session > WARNING: variable "f1" shadows a previously defined variable > LINE 2: declare f1 int; > ^ > foof > ------ > > (1 row) > > =#* create or replace function foof(f1 int) returns void as > $$ > declare f1 int; > begin > end $$ language plpgsql; > ERROR: variable "f1" shadows a previously defined variable > LINE 3: declare f1 int; > > > Currently, plpgsql_warnings is a boolean since there's only one warning we > implement. The idea is to make it a bit field of some kind in the future > when we add more warnings. Starting that work for 9.4 seemed like > overkill, though. I tried to keep things simple. > > > Regards, > Marko Tiikkaja >
