On 31.08.2011 18:20, Andrew Dunstan wrote:
I've just stumbled across this, which appears to be a regression from
8.4 that is present in 9.0 and master:
andrew=# create table foo (x int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"foo_pkey" for table "foo"
CREATE TABLE
andrew=# alter table foo rename x to y;
ALTER TABLE
andrew=# select attname from pg_attribute where attrelid =
'foo_pkey'::regclass;
attname
---------
x
(1 row)
In 8.4 the index attribute is renamed correctly.
That was intentional:
commit c176e122222c63844c0a2f3f8c568c3fe6c57d15
Author: Tom Lane <t...@sss.pgh.pa.us>
Date: Wed Dec 23 16:43:43 2009 +0000
Remove code that attempted to rename index columns to keep them in
sync with
their underlying table columns. That code was not bright enough to
cope with
collision situations (ie, new name conflicts with some other column
of the
index). Since there is no functional reason to do this at all,
trying to
upgrade the logic to be bulletproof doesn't seem worth the trouble.
This change means that both the index name and the column names of
an index
are set when it's created, and won't be automatically changed when the
underlying table columns are renamed. Neatnik DBAs are still free
to rename
them manually, of course.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
