Skip site navigation (1) Skip section navigation (2)

Re: Clobbered parameter names via DECLARE in PL/PgSQL

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Clobbered parameter names via DECLARE in PL/PgSQL
Date: 2012-04-17 09:50:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

there is VIP patch of plpgsql_check_function that supports this warning



2012/4/15 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2012/4/15 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> We can raise warning from CREATE OR REPLACE FUNCTION - but I would to
>>> like have plpgsql_check_function inside core - and it is better place
>>> for this and similar issues.
>> I agree.  This is a perfectly legal use of nested declaration scopes,
>> so it would be totally inappropriate to complain about it in normal
>> use of a plpgsql function.  On the other hand, it would probably be
>> sane and useful for CHECK FUNCTION to flag any case where an inner
>> declaration shadows an outer-scope name (not only the specific case
>> of topmost block vs function parameter).
> yes, it is very simple check there. There should be "levels" of
> warnings in future and performance or semantic warnings.
> But, we don't need to increase complexity of CHECK FUNCTION now. A
> design of CHECK FUNCTION was rich for this purposes. And we need to
> find way to push plpgsql_check_function to core first.
> Regards
> Pavel
>>                        regards, tom lane

Attachment: plpgsql_check_function-2012-04-17-1.patch.gz
Description: application/x-gzip (18.9 KB)

In response to

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2012-04-17 10:25:09
Subject: Re: Last gasp
Previous:From: Heikki LinnakangasDate: 2012-04-17 09:06:05
Subject: Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group