Thread: rename index fields bug
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 attnamefrom pg_attribute where attrelid = 'foo_pkey'::regclass; attname --------- x (1 row) In 8.4 the index attribute is renamed correctly. This only came to light because it caused a londiste failure, making londiste think that there wasn't a key field. Arguably londiste should be using pg_index.indkey, but this should still work right. cheers andrew
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
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