drop column name conflict
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t49576psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 10:55 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t49576_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t49576_3 && git checkout t49576_3Patchset v3 (message #3) is on t49576_3
Hi all,
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.
It seems a bit silly and unlikely that anyone would ever find
themselves in this scenario, but it also seems easy enough to fix as
shown by the attached patch.
Does anyone think this is worth fixing? If so I can submit it to the
current commitfest.
Thanks,
Joe Koshakow
Attachments:
v1-0001-Prevent-name-conflicts-when-dropping-a-column.patchtext/x-patch; charset=US-ASCII; name=v1-0001-Prevent-name-conflicts-when-dropping-a-column.patchDownload+24-2
Joseph Koshakow <koshy44@gmail.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
On Sat, May 4, 2024 at 11:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
Fair enough.
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.
Is there any interest in making this change? The attached patch could
use some cleanup, but seems to accomplish what's described. It's
definitely more involved than the previous one and may not be worth the
effort. If you feel that it's worth it I can clean it up, otherwise
I'll drop it.
Thanks,
Joe Koshakow