From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Koshakow <koshy44(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: drop column name conflict |
Date: | 2024-05-04 15:29:30 |
Message-ID: | 2918477.1714836570@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joseph Koshakow <koshy44(at)gmail(dot)com> writes:
> There's a rare edge case in `alter table` that can prevent users from
> dropping a column as shown below
> # create table atacc1(a int, "........pg.dropped.1........" int);
> CREATE TABLE
> # alter table atacc1 drop column a;
> ERROR: duplicate key value violates unique constraint
> "pg_attribute_relid_attnam_index"
> DETAIL: Key (attrelid, attname)=(16407, ........pg.dropped.1........)
> already exists.
I think we intentionally did not bother with preventing this,
on the grounds that if you were silly enough to name a column
that way then you deserve any ensuing problems.
If we were going to expend any code on the scenario, I'd prefer
to make it be checks in column addition/renaming that disallow
naming a column this way. What you propose here doesn't remove
the fundamental tension about whether this is valid user namespace
or not, it just makes things less predictable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michail Nikolaev | 2024-05-04 15:51:20 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Previous Message | Joseph Koshakow | 2024-05-04 14:37:34 | drop column name conflict |