Re: Clobbered parameter names via DECLARE in PL/PgSQL

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Brendan Jurd <direvus(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Clobbered parameter names via DECLARE in PL/PgSQL
Date: 2012-04-15 08:54:10
Message-ID: CAFj8pRA+GdinivdJND5VZ2oY364bf4_t1Q5fza=9M=KK-VWwnQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/4/15 Brendan Jurd <direvus(at)gmail(dot)com>:
> On 15 April 2012 17:55, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2012/4/15 Brendan Jurd <direvus(at)gmail(dot)com>:
>>> It turns out that in a PL/PgSQL function, you can DECLARE a variable
>>> using the same name as one of the function parameters.  This has the
>>> effect of clobbering the parameter, for example:
>>>
> ...
>>>
>>> I would suggest that if the user DECLAREs a variable with the same
>>> name as a parameter, it is very evidently a programming error, and we
>>> should raise the same "duplicate declaration" error.  I haven't yet
>>> looked at how difficult this would be to fix, but if there are no
>>> objections I would like to attempt a patch.
>>>
>>
>> I disagree - variables and parameters are in different namespace so
>> you can exactly identify variable and parameter. More - it is
>> compatibility break.
>>
>
> They may technically be in different namespaces, but the fact that the
> declared variable quietly goes ahead and masks the parameter locally,
> seems like a recipe for unexpected consequences.  It certainly was in
> my case, and I doubt I'm the first or the last to make that mistake.
>

I agree so this issue is relative usual. But I don't think so we can
use too hard solution like exclusion of parameter names, because it
just has not support in standard or PL/SQL or SQL/PSM. And we
introduce a few years ago different solution - function's namespace.

> Under these conditions, you now have "foo" which refers to the
> variable, and "declare_clobber.foo" which refers to the parameter.
> Not exactly a model of clarity, and it's also quite easy to miss the
> part of the PL/PgSQL docs mentioning this notation.

it is not well documented and should be documented better:

http://www.postgresql.org/docs/9.1/static/plpgsql-structure.html 39.2.
Structure of PL/pgSQL

Note: There is actually a hidden "outer block" surrounding the body of
any PL/pgSQL function. This block provides the declarations of the
function's parameters (if any), as well as some special variables such
as FOUND (see Section 39.5.5). The outer block is labeled with the
function's name, meaning that parameters and special variables can be
qualified with the function's name.

"39.3.1. Declaring Function Parameters

Note: These two examples are not perfectly equivalent. In the first
case, subtotal could be referenced as sales_tax.subtotal, but in the
second case it could not. (Had we attached a label to the inner block,
subtotal could be qualified with that label, instead. It should be
documented better."

>
> Perhaps it's a failure of imagination on my part, but I can't think of
> a legitimate reason for a programmer to deliberately use the same name
> to refer to a declared variable and a function parameter.  What would
> be the benefit?

it depends on level of nesting blocks. For simple functions there
parameter redeclaration is clean bug, but for more nested blocks and
complex procedures, there should be interesting using some local
variables with same identifier like some parameters and blocking
parameter's identifier can be same unfriendly feature like RO
parameters in previous pg versions.

I understand your motivation well, but solution should be warning, not
blocking. I think.

Regards

Pavel

>
> Cheers,
> BJ

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-04-15 09:00:36 Re: query planner does not canonicalize infix operators
Previous Message Brendan Jurd 2012-04-15 08:24:27 Re: Clobbered parameter names via DECLARE in PL/PgSQL