Re: plpgsql.warn_shadow
От | Pavel Stehule |
---|---|
Тема | Re: plpgsql.warn_shadow |
Дата | |
Msg-id | CAFj8pRDWWmEOFzn3f-u6DRjOUUw88KKAJ--2j4jchW_epp-pKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql.warn_shadow (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: plpgsql.warn_shadow
|
Список | pgsql-hackers |
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.On 1/15/14 2:00 PM, Florian Pflug wrote:On Jan15, 2014, at 13:32 , Marko Tiikkaja <marko@joh.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.
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
В списке pgsql-hackers по дате отправления: