Re: rename index fields bug

On 08/31/2011 11:24 AM, Heikki Linnakangas wrote:
> 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(at)sss(dot)pgh(dot)pa(dot)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.

Oh, I see. Thanks.

cheers

andrew