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 по дате отправления: