Re: plpgsql.warn_shadow

On 1/20/14 2:25 AM, Robert Haas wrote:
> On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja <marko(at)joh(dot)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