Re: plpgsql.warn_shadow - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql.warn_shadow
Date
Msg-id CAFj8pRDJQVKsQefaNtOvvJMqpJz2HGhq1JQi-BkRqhEO4N2HXg@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql.warn_shadow  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: plpgsql.warn_shadow
List pgsql-hackers



2014-03-18 13:23 GMT+01:00 Petr Jelinek <petr@2ndquadrant.com>:

On 14/03/14 13:12, Simon Riggs wrote:
On 14 March 2014 11:10, Pavel Stehule <pavel.stehule@gmail.com> wrote:


2014-03-14 12:02 GMT+01:00 Marko Tiikkaja <marko@joh.to>:

On 3/14/14 10:56 AM, Simon Riggs wrote:
The patch looks fine, apart from some non-guideline code formatting
issues.

I'm not sure what you're referring to.  I thought it looked fine.


Having looked at gcc and clang, I have a proposal for naming/API

We just have two variables

    plpgsql.compile_warnings = 'list'    default = 'none'

+1

    plpgsql.compile_errors = 'list'        default = 'none'

Only possible values in 9.4 are 'shadow', 'all', 'none'

what is compile_errors ? We don't allow to ignore any error now.
How about

plpgsql.additional_warnings = 'list'
plpgsql.additional_errors = 'list'


Agree that compile_errors dos not make sense, additional_errors and additional_warnings seems better, maybe plpgsql.extra_warnings and plpgsql.extra_errors?

extra* sounds better

Pavel
 

--
 Petr Jelinek                   http://www.2ndQuadrant.com/

 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.
Next
From: Simon Riggs
Date:
Subject: Re: plpgsql.warn_shadow