I wrote:
> The trouble with changing the index attnames for expressions is that it
> increases the risk of collisions with attnames for regular index
> columns. You can hit that case today:
> regression=# create table foo (f1 int, f2 text);
> CREATE TABLE
> regression=# create index fooi on foo(f1, lower(f2));
> CREATE INDEX
> regression=# \d fooi
> Index "public.fooi"
> Column | Type | Definition
> -----------------+---------+------------
> f1 | integer | f1
> pg_expression_2 | text | lower(f2)
> btree, for table "public.foo"
> regression=# alter table foo rename f1 to pg_expression_2;
> ERROR: duplicate key value violates unique constraint "pg_attribute_relid_attnam_index"
> DETAIL: Key (attrelid, attname)=(64621, pg_expression_2) already exists.
> but it's not exactly probable that someone would name a column
> pg_expression_N. The risk goes up quite a lot if we might use simple
> names like "abs" or "lower" for expression columns.
It strikes me that the easiest way to deal with this is just to get rid
of the code in renameatt() that tries to rename index columns to agree
with the underlying table columns. That code is not nearly bright
enough to deal with collisions, and furthermore it seems rather
inconsistent to try to rename index columns (which are not very
user-visible in the first place) while not renaming the indexes
themselves (which surely are user-visible). There was some marginal
excuse for doing it back when \d didn't show the index column
definition; but now that it does, I don't think the behavior is worth
expending effort on.
regards, tom lane