From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql.warn_shadow |
Date: | 2014-01-26 15:49:46 |
Message-ID: | 3DAC5647-7DF8-44AB-B766-49DBE59FEDFF@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan26, 2014, at 10:19 , Simon Riggs <simon(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-01-26 15:53:43 | Re: plpgsql.warn_shadow |
Previous Message | Magnus Hagander | 2014-01-26 14:53:25 | effective_cache_size calculation overflow |