Re: rename index fields bug

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 <tgl@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