Re: plpgsql.warn_shadow
От | Florian Pflug |
---|---|
Тема | Re: plpgsql.warn_shadow |
Дата | |
Msg-id | 3DAC5647-7DF8-44AB-B766-49DBE59FEDFF@phlo.org обсуждение исходный текст |
Ответ на | Re: plpgsql.warn_shadow (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: plpgsql.warn_shadow
Re: plpgsql.warn_shadow |
Список | pgsql-hackers |
On Jan26, 2014, at 10:19 , Simon Riggs <simon@2ndQuadrant.com> wrote: > Also, having > plpgsql.warnings_as_errors = off (default) | on > makes sense and should be included in 9.4 I still think this is a bad idea, for the same reasons I don't like consistent_into (discussed in a separate thread). But these objections would go away if restricted this to function creation time only. So even with warnings_as_errors=on, you could still *call* a function that produces a warning, but not *create* one. We could then integrate this with check_function_bodies, i.e. add a third possible value "error_on_warnings" to that GUC, instead of having a separate GUC for this. > Putting this and all future options as keywords seems like a poor > choice. Indeed, the # syntax proposed isn't even fully described on > list here, nor are examples given in tests. My feeling is that nobody > even knows that is being proposed and would likely cause more > discussion if they did. So I wish to push back the # syntax to a later > release when it has had more discussion. It would be good if you could > lead that discussion in later releases. +1 best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: