Shall we just get rid of plpgsql's RENAME?
От | Tom Lane |
---|---|
Тема | Shall we just get rid of plpgsql's RENAME? |
Дата | |
Msg-id | 7390.1257384842@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Shall we just get rid of plpgsql's RENAME?
Re: Shall we just get rid of plpgsql's RENAME? Re: Shall we just get rid of plpgsql's RENAME? Re: Shall we just get rid of plpgsql's RENAME? Re: Shall we just get rid of plpgsql's RENAME? |
Список | 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
В списке pgsql-hackers по дате отправления: