From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Florian Pflug <fgp(at)phlo(dot)org>, Marti Raudsepp <marti(at)juffo(dot)org> |
Subject: | Re: plpgsql.warn_shadow |
Date: | 2014-03-14 09:56:13 |
Message-ID: | CA+U5nMKbMntpGR3dXv4Zj0pJKw6=tPvCj1=nYK-5GLW_3dE3rA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3 February 2014 20:17, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 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.
The patch looks fine, apart from some non-guideline code formatting issues.
Having looked at gcc and clang, I have a proposal for naming/API
We just have two variables
plpgsql.compile_warnings = 'list' default = 'none'
plpgsql.compile_errors = 'list' default = 'none'
Only possible values in 9.4 are 'shadow', 'all', 'none'
If we can agree something quickly then we can commit this for 9.4
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2014-03-14 10:32:20 | Archive recovery won't be completed on some situation. |
Previous Message | Amit Kapila | 2014-03-14 09:38:41 | Re: About the portal in postgres |