Re: Clobbered parameter names via DECLARE in PL/PgSQL - Mailing list pgsql-hackers
From | Pavel Stehule |
---|---|
Subject | Re: Clobbered parameter names via DECLARE in PL/PgSQL |
Date | |
Msg-id | CAFj8pRA+GdinivdJND5VZ2oY364bf4_t1Q5fza=9M=KK-VWwnQ@mail.gmail.com Whole thread Raw |
In response to | Re: Clobbered parameter names via DECLARE in PL/PgSQL (Brendan Jurd <direvus@gmail.com>) |
Responses |
Re: Clobbered parameter names via DECLARE in PL/PgSQL
|
List | pgsql-hackers |
2012/4/15 Brendan Jurd <direvus@gmail.com>: > On 15 April 2012 17:55, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> 2012/4/15 Brendan Jurd <direvus@gmail.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
pgsql-hackers by date: