Re: plpgsql.warn_shadow

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

In response to

Browse pgsql-hackers by date

  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?