[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] rename index fields bug
From:       Andrew Dunstan <andrew () dunslane ! net>
Date:       2011-08-31 15:36:26
Message-ID: 4E5E54FA.70103 () dunslane ! net
[Download RAW message or body]



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



Oh, I see.  Thanks.

cheers

andrew



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]