Re: plpgsql.warn_shadow

2014/1/15 Marko Tiikkaja <marko(at)joh(dot)to>

> On 1/15/14 2:00 PM, Florian Pflug wrote:
>
>> On Jan15, 2014, at 13:32 , Marko Tiikkaja <marko(at)joh(dot)to> wrote:
>>
>>> On 1/15/14 1:23 PM, Florian Pflug wrote:
>>>
>>>> The fact that it's named plpgsql.warnings already clearly documents
>>>> that this only affects plpgsql. But whether a particular warning is emitted
>>>> during compilation or during execution it largely irrelevant, I think. For
>>>> example, if we called this compiler_warning, we'd couldn't add a warning
>>>> which triggers when SELECT .. INTO ingores excessive rows.
>>>>
>>>
>>> There is the fact that something being a "compiler warning" gives you an
>>> idea on its effects on performance. But maybe that would be better
>>> described in the documentation (perhaps even more accurately).
>>>
>>> I like the idea of warning about SELECT .. INTO, though, but that one
>>> could have a non-negligible performance penalty during execution.
>>>
>>
>> I'm not overly concerned about that. I image people would usually enable
>> warnings during development, not production.
>>
>
> 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)

>
>
> Regards,
> Marko Tiikkaja
>