Re: plpgsql.warn_shadow - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: plpgsql.warn_shadow
Date
Msg-id 52F6E296.8060307@joh.to
Whole thread Raw
In response to Re: plpgsql.warn_shadow  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 1/27/14, 12:04 PM, Simon Riggs wrote:
> Florian's point was well made and we must come up with something that
> allows warning/errors at compile time and once accepted, nothing at
> run time.

I've been thinking about this, and I'm not sure I like this idea all 
that much.  For compile-time warnings this would probably be the ideal 
behaviour, but if we were to add any run-time warnings (e.g. 
consistent_into) I'm not sure how I would use such a feature.

Say I run my test suite with all warnings enabled, and now I want to 
know that it didn't produce any warnings.  How would I do that?  I guess 
I could grep the log for warning messages, but then I'd have to maintain 
a list of all warnings somewhere, which seems quite ugly.  A special 
SQLSTATE for PL/PgSQL warnings doesn't seem that much better.

But maybe I'm overthinking this and we'd only ever have one runtime 
warning (or maybe none at all, even) and this would not be an issue in 
practice.


Regards,
Marko Tiikkaja



pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Changeset Extraction v7.5
Next
From: Peter Eisentraut
Date:
Subject: Re: clang's -Wmissing-variable-declarations shows some shoddy programming