Shall we just get rid of plpgsql's RENAME?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Shall we just get rid of plpgsql's RENAME?
Date: 2009-11-05 01:34:02
Message-ID: 7390.1257384842@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

According to
http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS
the RENAME declaration in plpgsql has been known broken since PG 7.3.
Nobody has bothered to fix it. Shall we just rip it out?

The reason I'm looking at it right now is that it's quite unclear
what it is supposed to mean. Consider

DECLARE x int;
BEGIN
... some stuff ...
DECLARE y int;
RENAME x to z;
BEGIN
... other stuff ...
END;
... yet more stuff ...
END;

What effect should the RENAME have on the name of "x" as seen by the
code outside the inner DECLARE block? In the current implementation,
the RENAME would change "x" to "z" as seen by the code following the
inner block, which seems pretty unexpected. What's worse, once we
have support in there for re-parsing SQL queries, the RENAME could
retroactively affect the behavior of the code before the inner block,
which is surely unexpected.

As the documentation points out, there doesn't seem to be any real
use for RENAME that isn't served as well or better by ALIAS, so
I'm not especially interested in trying to puzzle out what it should
do or how to make it do that. I want to just remove it. Or we could
make it an alternative spelling for ALIAS. Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2009-11-05 03:43:22 Re: Shall we just get rid of plpgsql's RENAME?
Previous Message KaiGai Kohei 2009-11-05 00:57:03 Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns