Re: plpgsql.warn_shadow - Mailing list pgsql-hackers

From Robert Haas
Subject Re: plpgsql.warn_shadow
Date
Msg-id CA+TgmobM8F2ZnZZz9ZTtDG6+31BZLkGBVXxikNxLz_8m-viRYA@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Responses Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja <marko@joh.to> wrote:
> On 1/17/14 11:26 AM, Pavel Stehule wrote:
>>
>> After some thinking I don't think so this design is not good. It  changing
>> a working with exception (error) levels - and it is not consistent with
>> other PostgreSQL parts.
>>
>> A benefit is less than not clean configuration. Better to solve similar
>> issues via specialized plpgsql extensions or try to help me push
>> plpgsql_check_function to core. It can be a best holder for this and
>> similar checks.
>
>
> 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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: What is happening on buildfarm member crake?
Next
From: Craig Ringer
Date:
Subject: Re: [v9.4] row level security