On 1/20/14 2:25 AM, Robert Haas wrote:
On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja <ma...@joh.to> wrote:
I see these as being two are different things. There *is* a need for a
full-blown static analyzer for PL/PgSQL, but I don't think it needs to be in
core. However, there seems to be a number of pitfalls we could warn the
user about with little effort in core, and I think those are worth doing.
I don't want to be overly negative, but that sounds sort of like
you're saying that it's not worth having a good static analyzer in
core, but that you are in favor of having a bad one.
Sort of, yeah.
My experience of static analyzers is that it's not really feasible to
try and fix all code they think might be faulty, and I don't expect a
PL/PgSQL one to be any different. The idea behind these warnings (to
me, at least) has been that they're simple and uncontroversial enough
that it's feasible to say "never commit code which produces warnings
upon compilation". I realize that where to draw that line is a bit
arbitrary and subjective, and I don't expect everyone to agree with me
on the exact list of these "warnings".
I personally tend to think a static analyzer is a better fit than
adding a whole laundry list of pragmas. Most people won't remember to
turn them all on anyway> , and those who do will find that it gets
pretty tedious after we have more than about two of them.
What's so hard about plpgsql.warnings='all'? Or if the fact that it's a
list is your concern, I'm not going to oppose to making it a boolean.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
