Re: plpgsql.warn_shadow

2014-01-26 Florian Pflug <fgp(at)phlo(dot)org>

> 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.
>

+1 behave - and please, better name

Regards

Pavel

>
> 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
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>