From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PL/pgSQL RENAME functionality in TODOs |
Date: | 2007-02-02 05:33:22 |
Message-ID: | 97724FF0-5ED3-4F23-AAF7-2F151B0E29A1@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-02-02 05:43:04 | Re: column ordering, was Re: [PATCHES] Enums patch v2 |
Previous Message | Jim Nasby | 2007-02-02 05:20:36 | Re: Logging Lock Waits |