Re: plpgsql.warn_shadow
От | Pavel Stehule |
---|---|
Тема | Re: plpgsql.warn_shadow |
Дата | |
Msg-id | CAFj8pRAVrjx-D66ZhtZeNBQiQQ5yxh4SsNWMQyJV2H1WxfTrvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql.warn_shadow (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: plpgsql.warn_shadow
Re: plpgsql.warn_shadow |
Список | pgsql-hackers |
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.
2014-02-03 Marko Tiikkaja <marko@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
В списке pgsql-hackers по дате отправления: