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-15 16:12:24
Message-ID: CAFj8pRC3YDZW9n9TyfAy3iN5RQAU3UZt_vU1Wa=Yykf+GfTn6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-04-15 16:29:39 Re: BUG #6572: The example of SPI_execute is bogus
Previous Message Tom Lane 2012-04-15 16:01:11 Re: Last gasp