plpgsql.warn_shadow
От | Marko Tiikkaja |
---|---|
Тема | plpgsql.warn_shadow |
Дата | |
Msg-id | 52D5D791.4010204@joh.to обсуждение исходный текст |
Ответы |
Re: plpgsql.warn_shadow
Re: plpgsql.warn_shadow Re: plpgsql.warn_shadow Re: plpgsql.warn_shadow |
Список | pgsql-hackers |
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; SET =#* create function test(in1 int, in2 int) -#* returns table(out1 int, out2 int) as $$ $#* declare $#* IN1 text; $#* IN2 text; $#* out1 text; $#* begin $#* $#* declare $#* out2 text; $#* in1 text; $#* begin $#* end; $#* end$$ language plpgsql; WARNING: variable "in1" shadows a previously defined variable LINE 4: IN1 text; ^ WARNING: variable "in2" shadows a previously defined variable LINE 5: IN2 text; ^ WARNING: variable "out1" shadows a previously defined variable LINE 6: out1 text; ^ WARNING: variable "out2" shadows a previously defined variable LINE 10: out2 text; ^ WARNING: variable "in1" shadows a previously defined variable LINE 11: in1 text; ^ CREATE FUNCTION 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. Let me know what you think so I can either cry or clean the patch up. Regards, Marko Tiikkaja
Вложения
В списке pgsql-hackers по дате отправления: