Re: [HACKERS] 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 c176e12c63844c0a2f3f8c568c3fe6c57d15 Author: Tom Lane Date: Wed Dec 23 16:43:43 2009 + 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
Re: [HACKERS] 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 c176e12c63844c0a2f3f8c568c3fe6c57d15 Author: Tom Lane Date: Wed Dec 23 16:43:43 2009 + 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 attname from 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
