Propagate column renames to FK and unique constraints in the table dialog (#9060)#10046
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
WalkthroughThis PR fixes a bug where renaming a column in the Create Table dialog failed to update references to that column within foreign key and unique constraint definitions by extending depChange handlers to propagate the new column name; tests and release notes were added. ChangesColumn Rename Propagation in Constraints
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
8c5f1c7 to
eb9f462
Compare
In the new-table dialog, the primary key already updated its column references when a column was renamed, but foreign key and unique constraint definitions did not, leaving them pointing at the old name. Mirror the PK rename-propagation in the foreign_key and unique_constraint depChange handlers (and add 'columns' to the unique constraint deps so it fires on column changes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
eb9f462 to
c41ec7a
Compare
There was a problem hiding this comment.
Pull request overview
Fixes column-rename propagation in the Create Table dialog so constraint definitions don’t keep referencing stale column names (Issue #9060), preventing incorrect/broken generated DDL.
Changes:
- Propagate renamed column names into
foreign_key[].columns[].local_columnwhen editing table columns in the Create Table dialog. - Propagate renamed column names into
unique_constraint[].columns[].columnand ensure the unique-constraint handler is triggered on table column edits by addingcolumnstodeps. - Document the fix in the v9.16 release notes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| web/pgadmin/browser/server_groups/servers/databases/schemas/tables/static/js/table.ui.js | Adds rename-propagation logic for FK + unique constraints when a table column name changes. |
| docs/en_US/release_notes_9_16.rst | Adds a bug-fix entry referencing Issue #9060. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Remap unique constraint INCLUDE columns on rename. The INCLUDE list
holds bare name strings (not {column} objects), so renaming an
included column previously emitted stale DDL. Now mirrors the
primary key INCLUDE handling.
- Add regression tests covering rename propagation in depChange for
foreign_key and unique_constraint, including the unique constraint
INCLUDE case.
- Correct the release note wording from "Create/Edit Table" to
"Create Table"; the propagation only runs on the new-table path
(state.oid === undefined).
asheshv
left a comment
There was a problem hiding this comment.
Approach is right and the new tests cover the headline cases. Two scope items worth addressing here rather than in a follow-up:
- Exclusion constraints have an
includelist of bare column-name strings — same shape as the unique-constraintincludeyou just fixed. The exclusion case isn't covered by the outerdepChange, leaving it half-fixed for INCLUDE-clause constraints. - The outer
columnsmapping for FK and unique intable.ui.jsis largely redundant — the innerdepChangehandlers inforeign_key.ui.jsandunique_constraint.ui.jsalready updatelocal_column/columnin place in create-table mode. The net-new fix is really the uniqueincludemap (and would-be exclusioninclude). Worth trimming so the propagation isn't claimed in two places.
Summary
Fixes #9060.
In the Create Table dialog, renaming a column already propagated to the primary key definition, but foreign key and unique constraint definitions kept referencing the old column name — producing wrong/broken DDL.
Fix: mirror the existing PK rename-propagation logic in the
foreign_keyandunique_constraintdepChangehandlers — on a columnnameSET_VALUEin a new table, rewrite the old name to the new name in each FK'scolumns[].local_columnand each unique constraint'scolumns[].column. Also added'columns'to the unique constraint'sdepsso itsdepChangefires on column edits (FK already had it).Changes
table.ui.js(one file)🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Documentation
Tests