| From: | lakshmi <lakshmigcdac(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | 金 <jinbinge(at)126(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com> |
| Subject: | Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object |
| Date: | 2026-04-30 04:57:00 |
| Message-ID: | CAEvyyTjgSuQ6GvNjxp0+1w8uKAzettjbaOBXZ7uX-KDeA4u8jw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I tested the latest v8-0001 patch on current master and wanted to share my
observations.
Before applying the patch, when dropping a column, constraints and indexes
that referenced the whole row (for example, CHECK (ts = ROW(...)) or
expressions using ts) were not removed. This left the table in an
inconsistent state and resulted in errors during inserts.
After applying the patch, these objects are correctly detected and removed
when the column is dropped. The table remains clean, and inserts work as
expected.
I also tried a few additional scenarios:
-
DROP COLUMN with CASCADE—behaved as expected, no leftover objects
-
normal column-level constraints — still handled correctly (no regression)
-
multiple whole-row constraints — all removed properly
-
ALTER COLUMN TYPE — correctly throws an error when a whole-row
constraint exists
Overall, the behavior looks correct and consistent based on these tests.
Thanks for working on this!
lakshmi
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2026-04-30 04:59:04 | Bug in logical decoding with DDL and subtransactions |
| Previous Message | Ayush Tiwari | 2026-04-30 04:53:34 | Re: [PATCH] Fix stale relation close in sequence synchronization |