Re: plpgsql.warn_shadow - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: plpgsql.warn_shadow
Date
Msg-id 52D69422.60809@joh.to
Whole thread Raw
In response to Re: plpgsql.warn_shadow  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: plpgsql.warn_shadow  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On 1/15/14 2:27 PM, Pavel Stehule wrote:
> 2014/1/15 Marko Tiikkaja <marko@joh.to>
>> Yeah, me neither, it's just something that needs to be communicated very
>> clearly.  So probably just a list  plpgsql.warnings  would be the most
>> appropriate then.
>>
>
> I am thinking so the name is not good. Changing handling warnings is messy
> - minimally in Postgres, where warnings and errors are different creatures.
>
> what about
>
> plpgsql.enhanced_checks = (none | warning | error)

You crammed several suggestions into one here:
  1) You're advocating the ability to turn warnings into errors.  This 
has been met with some resistance.  I think it's a useful feature, but I 
would be happy with just having warnings available.  2) This syntax doesn't allow the user to specify a list of
warnings
 
to enable.  Which might be fine, I guess.  I imagine the normal approach 
would be to turn all warnings on anyway, and possibly fine-tune with 
per-function directives if some functions do dangerous things on purpose.  3) You want to change the name to
"enhanced_checks". I still think 
 
the main feature is about displaying warnings to the user.  I don't 
particularly like this suggestion.


Regards,
Marko Tiikkaja



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql.warn_shadow