plpgsql.warn_shadow

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: plpgsql.warn_shadow
Date: 2014-01-15 00:34:25
Message-ID: 52D5D791.4010204@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
shadowing_v1.patch text/plain 5.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-01-15 00:36:55 Re: Linux kernel impact on PostgreSQL performance
Previous Message Jim Nasby 2014-01-15 00:22:52 Re: Linux kernel impact on PostgreSQL performance