Inherited columns are not removed from a table's Columns tab after removing the parent table from "Inherited from"
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, postgresql, python
Research direction
Start with the coll_inherits deferredDepChange removal logic in web/pgadmin/browser/server_groups/servers/databases/schemas/tables/static/js/table.ui.js and compare it with get_formatted_columns in web/pgadmin/browser/server_groups/servers/databases/schemas/tables/columns/utils.py. Check get_columns_for_table.sql and the properties-fetch path to confirm inheritedid is preserved after reopening. Done means removing a saved parent removes its inherited columns without affecting the child's own columns, with the relevant tests passing.
Written by the indexing model from the issue text.
Description
Describe the bug
When a parent table is added under "Inherited from" on a table's Columns tab, its columns are correctly pulled into the child's column list as read-only inherited columns. However, once the table has been saved and the Properties dialog reopened, removing that parent from "Inherited from" does not remove its columns from the Columns tab — they remain in the grid and are subsequently treated/saved as the child's own columns.
This is a separate, still-open issue from #10179 / #10332 — that fix addressed marking inherited columns read-only, not this removal path.
To Reproduce
- Open the Properties dialog of a table (or create a new one).
- On the Columns tab, add a parent table under "Inherited from".
- The parent's columns show up in the child's column list as inherited (read-only) columns.
- Save.
- Reopen the table's Properties dialog.
- Remove the parent table from "Inherited from".
- The previously-inherited columns stay in the Columns tab instead of being removed, and the list is what gets persisted on the next Save.
(Note: if the parent is added and removed within the same, unsaved dialog session, the columns are correctly removed — the bug only appears after a save + reopen cycle.)
Expected behavior
Removing a table from "Inherited from" should remove that parent's contributed columns from the child's Columns tab, leaving only the columns the child still legitimately owns — mirroring ALTER TABLE child NO INHERIT parent in PostgreSQL, and matching the "add" side of the same control.
Error message
N/A — no error is raised; this is a silent data/UI bug.
Screenshots
(attach if available)
Desktop (please complete the following information):
- OS: (fill in)
- pgAdmin version: 9.18-dev / master (
f09776c22or later, includes #10332) — (adjust to your actual build) - Mode: (Desktop or Server)
- Browser (if running in server mode): (fill in)
- Package type: (fill in)
Additional context
Root cause: table.ui.js's coll_inherits field's deferredDepChange "Remove columns logic" (around table.ui.js:685-706) removes stale columns by matching col.inheritedid == removeOid. That field is only present on columns fetched interactively via the get_columns endpoint (get_columns_for_table.sql, which returns both inheritedfrom and inheritedid).
Once the table is saved and reopened, its columns instead come from the properties fetch. get_formatted_columns (columns/utils.py, around L327-332) queries the same SQL for the parent's columns but only copies other_col['inheritedfrom'] into col['inheritedfromtable'] — it drops other_col['inheritedid'], even though it's available in the same row. So reopened columns carry no inheritedid, and the frontend's removal filter above can never match them — the parent's columns are stranded in the grid indefinitely.
Suggested fix: also stamp col['inheritedid'] = other_col['inheritedid'] in get_formatted_columns, so the existing frontend removal match works the same way whether a column was added interactively or loaded from a saved table's properties.
Verified against pgadmin-org/pgadmin4 master, commit f09776c22 (2026-09-15), which already includes the merged #10332 fix (153e3273d).
- Dominant language
- Python
- Stars
- 3.9k
- Forks
- 904
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 28
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pgadmin-org/pgadmin4
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
pgadmin-org/pgadmin4#10503 · 1 comment ·
Maintainers usually reply within 1 day
-
Query Tool: first 4 MB of a large file is loaded twice when a later chunk isn't valid UTF-8Possibly taken @dev-hari-prasad claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
pgadmin-org/pgadmin4#10462 · 1 comment ·
Maintainers usually reply within 1 day
-
Feature
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pgadmin-org/pgadmin4#10426 · 3 comments ·
Maintainers usually reply within 1 day
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
pgadmin-org/pgadmin4#10424 ·
Maintainers usually reply within 1 day
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
pgadmin-org/pgadmin4#10418 ·
Maintainers usually reply within 1 day
All issues in pgadmin-org/pgadmin4
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
NVIDIA/earth2studio#1241 ·
Maintainers usually reply within 3 days
-
docs(types): update the collection binding note now that typed collections shipped in pycubrid 1.9.0Opendocumentation priority: low size: S
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
cubrid-lab/sqlalchemy-cubrid#768 ·
Maintainers usually reply within 1 day
-
bug help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 65/100
ansys/pydpf-core#3547 ·
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
OktoLabsAI/okto-pulse#114 ·
Maintainers usually reply within 1 day