From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql.warn_shadow |
Date: | 2014-01-15 05:16:26 |
Message-ID: | 52D619AA.9080606@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/14/14, 6:34 PM, Marko Tiikkaja wrote:
> Hi all!
>
> It's me again, trying to find a solution to the most common mistakes I make. This time it's accidental shadowing of variables, especially input variables. I've wasted several hours banging my head against the wall while shouting "HOW CAN THIS VARIABLE ALWAYS BE NULL?". I can't believe I'm the only one. To give you a rough idea on how it works:
>
> =# set plpgsql.warn_shadow to true;
<snip>
> No behaviour change by default. Even setting the GUC doesn't really change behaviour, just emits some warnings when a potentially faulty function is compiled.
I like it, though I'm not sure I'm a fan of WARNING by default... perhaps plpgsql.warn_shadow_level that accepts a log level to use? That way you could even disallow this pattern completely if you wanted (plpgsql.warn_shadow_level = ERROR).
FWIW, this is just one kind of programming pattern I'd like to enforce (and not just within plpgsql)... I wish there was a way to plug into the parser. I also wish there was a good way to enforce SQL formatting...
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2014-01-15 05:21:34 | Re: WAL Rate Limiting |
Previous Message | Tom Lane | 2014-01-15 05:15:50 | Re: Portal suddenly disappears? |