Re: plpgsql.warn_shadow

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: plpgsql.warn_shadow
Дата
Msg-id 52D619AA.9080606@nasby.net
обсуждение исходный текст
Ответ на plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
Список 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
CANTHIS 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
apotentially 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
levelto 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
wasa way to plug into the parser. I also wish there was a good way to enforce SQL formatting...
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Portal suddenly disappears?
Следующее
От: Dave Chinner
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance