From: | imad <immaad(at)gmail(dot)com> |
---|---|
To: | "Jim Nasby" <decibel(at)decibel(dot)org> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PL/pgSQL RENAME functionality in TODOs |
Date: | 2007-02-02 18:40:05 |
Message-ID: | 1f30b80c0702021040h699d1d70m9cf44005b7b145c6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/2/07, Jim Nasby <decibel(at)decibel(dot)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(at)nasby(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-02-02 18:43:39 | Re: --enable-debug does not work with gcc |
Previous Message | Stephan Szabo | 2007-02-02 18:35:05 | Re: Referential Integrity and SHARE locks |