BUG #19757: attname in pg_attribute not strictly updated when renaming a column

Started by PG Bug reporting form8 days ago2 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 19757
Logged by: Jonas
Email address: jonas-lugner@gmx.de
PostgreSQL version: 16.15
Operating system: Alpine Linux via Docker
Description:

Consider the following Code:

CREATE TABLE employees (
email VARCHAR(255) UNIQUE
);

ALTER TABLE employees RENAME COLUMN email TO contact_email;

This generates two entries, but for one of those the attname remains `email`
and is not updated to `contact_email` accordingly.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: PG Bug reporting form (#1)
Re: BUG #19757: attname in pg_attribute not strictly updated when renaming a column

PG Bug reporting form <noreply@postgresql.org> writes:

Consider the following Code:

CREATE TABLE employees (
email VARCHAR(255) UNIQUE
);

ALTER TABLE employees RENAME COLUMN email TO contact_email;

This generates two entries, but for one of those the attname remains `email`
and is not updated to `contact_email` accordingly.

This is not a bug.

The second pg_attribute row you are seeing is for the index
underlying the unique constraint. Index column names are an
arbitrary implementation detail, and we don't try to make them
track table column names. For that matter, we don't rename
the index itself either. So, looking at the behavior of your
example with psql:

regression=# CREATE TABLE employees (
email VARCHAR(255) UNIQUE
);
CREATE TABLE
regression=# \d employees
Table "public.employees"
Column | Type | Collation | Nullable | Default
--------+------------------------+-----------+----------+---------
email | character varying(255) | | |
Indexes:
"employees_email_key" UNIQUE CONSTRAINT, btree (email)

regression=# \d employees_email_key
Index "public.employees_email_key"
Column | Type | Key? | Definition
--------+------------------------+------+------------
email | character varying(255) | yes | email
unique, btree, for table "public.employees"

regression=# ALTER TABLE employees RENAME COLUMN email TO contact_email;
ALTER TABLE
regression=# \d employees
Table "public.employees"
Column | Type | Collation | Nullable | Default
---------------+------------------------+-----------+----------+---------
contact_email | character varying(255) | | |
Indexes:
"employees_email_key" UNIQUE CONSTRAINT, btree (contact_email)

regression=# \d employees_email_key
Index "public.employees_email_key"
Column | Type | Key? | Definition
--------+------------------------+------+---------------
email | character varying(255) | yes | contact_email
unique, btree, for table "public.employees"

regards, tom lane