Re: PL/pgSQL RENAME functionality in TODOs

Hello,

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.

Regards
Pavel Stehule

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/

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)

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

imad <immaad(at)gmail(dot)com> writes:
> So, should we still consider it a ToDo?

Whatever you think about the rename-in-same-block-as-declared case,
it's still broken, as per my example showing that the effects are not
limited to the containing block. However, considering that no one
has taken an interest in fixing it since 7.2, it's obviously not a
high-priority feature.

regards, tom lane