Re: PL/pgSQL RENAME functionality in TODOs
От | imad |
---|---|
Тема | Re: PL/pgSQL RENAME functionality in TODOs |
Дата | |
Msg-id | 1f30b80c0702021040h699d1d70m9cf44005b7b145c6@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PL/pgSQL RENAME functionality in TODOs (Jim Nasby <decibel@decibel.org>) |
Ответы |
Re: PL/pgSQL RENAME functionality in TODOs
|
Список | pgsql-hackers |
On 2/2/07, Jim Nasby <decibel@decibel.org> wrote: > On Feb 1, 2007, at 5:08 AM, Pavel Stehule wrote: > > std. use rename only for triggers and variables new and old. It has > > sense. I don't see sense for rename in clasic plpgsql functions. > > There was one reason, rename unnamed $params. But currently plpgsql > > support named params and this reason is obsolete. > > Unless things have changed it can be a real PITA to deal with plpgsql > variables that share the same name as a field in a table. IIRC > there's some cases where it's not even possible to unambiguously > refer to the plpgsql variable instead of the field. > > For internal variables there's a decent work-around... just prefix > all variables with something like v_. But that's pretty ugly for > parameters... get_user(user_id int) is certainly a nicer interface > than get_user(p_user_id int). > > But I think a way to get around that would be to RENAME the arguments > in the DECLARE section, so user_id could become p_user_id under the > covers. > > So perhaps there is still a point to RENAME after-all, at least for > paramaters. > -- > Jim Nasby jim@nasby.net > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) Parameters can be renamed in 8.2. The only thing which does not work is renaming a variable immediately after its declaration which is a useless functionality. So, should we still consider it a ToDo? -- Imad www.EnterpriseDB.com
В списке pgsql-hackers по дате отправления: