Re: rename index fields bug

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: rename index fields bug
Дата
Msg-id 4E5E54FA.70103@dunslane.net
обсуждение исходный текст
Ответ на Re: rename index fields bug  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers

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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: casting between range types
Следующее
От: Robert Haas
Дата:
Сообщение: Re: casting between range types