Re: plpgsql.warn_shadow - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql.warn_shadow
Date
Msg-id CAFj8pRB95PuyrKfYenjY5v5Jgmdr9GjUBvk4CWyZ0ztLzZnc-g@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
<p dir="ltr"><br /> Dne 3.2.2014 21:48 "Marko Tiikkaja" <<a href="mailto:marko@joh.to">marko@joh.to</a>>
napsal(a):<br/> ><br /> > On 2014-02-03 9:17 PM, Pavel Stehule wrote:<br /> >><br /> >> I am not
happyfrom "warnings_as_error"<br /> >><br /> >> what about "stop_on_warning" instead?<br /> ><br />
><br/> > abort_compilation_on_warning?  I think if we're not going to make it more clear that warnings are only
promotedto errors at CREATE FUNCTION time, we can't do much better than warnings_as_errors.<br /> ><br /> ><br />
>>second question: should be these errors catchable or uncatchable?<br /> >><br /> >> When I work on
largeproject, where I had to use some error handler of<br /> >> "EXCEPTION WHEN OTHERS" I found very strange and
notuseful so all syntax<br /> >> errors was catched by this handler. Any debugging was terribly difficult<br />
>>and I had to write plpgsql_lint as solution.<br /> ><br /> ><br /> > Is this really an issue
consideringthese errors can only happen when someone runs CREATE FUNCTION?<p dir="ltr">Can you look, pls, what
terminologyis used in gcc, clang, perl or python.<p dir="ltr">I agree with idea, but proposed names I have not
associatedwith something.<p dir="ltr">Regards<p dir="ltr">Pavel<br /> ><br /> ><br /> > Regards,<br /> >
MarkoTiikkaja<br /> 

pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: plpgsql.warn_shadow
Next
From: Jeff Janes
Date:
Subject: Re: Wait free LW_SHARED acquisition - v0.2