Re: PL/pgSQL RENAME functionality in TODOs - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: PL/pgSQL RENAME functionality in TODOs
Date
Msg-id 97724FF0-5ED3-4F23-AAF7-2F151B0E29A1@decibel.org
Whole thread Raw
In response to Re: PL/pgSQL RENAME functionality in TODOs  ("Pavel Stehule" <pavel.stehule@hotmail.com>)
Responses Re: PL/pgSQL RENAME functionality in TODOs  (imad <immaad@gmail.com>)
List pgsql-hackers
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)




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Estimation error in n_dead_tuples
Next
From: Jim Nasby
Date:
Subject: Re: Talks for OSCON? Only 5 days left!