Fixes #587: Use actual FK target column in migration 0011

[bctiemann]

Fixes: #587

Summary

Migration 0011_non_deferrable_fk_constraints reconstructs DEFERRABLE FK constraints as non-DEFERRABLE. The REFERENCES clause hardcoded "id" as the target column, but COTs created under multi-table inheritance use customobject_ptr_id as their primary key. PostgreSQL rejects the constraint because the column id literally does not exist on those tables.

The fix: the query already joins information_schema.constraint_column_usage, which records the actual referenced column name. Adding ccu.column_name AS foreign_column_name to the SELECT and using it in the REFERENCES clause makes the migration correct for both standard (id) and MTI (customobject_ptr_id) COTs.

Local verification

Verified with a direct DB script that:

1. Creates an MTI-style custom_objects_test_* table (PK=customobject_ptr_id) and a through table with a DEFERRABLE FK pointing at it
2. Runs the original migration logic → confirmed ProgrammingError: column "id" referenced in foreign key constraint does not exist
3. Restores the DEFERRABLE constraint, runs the fixed migration logic → succeeds, constraint rebuilt as non-DEFERRABLE referencing customobject_ptr_id

Test plan

• Bug reproduced and fix verified locally via DB-level script
• Confirm on a real pre-0.5.x install with an MTI COT that has M2M fields

🤖 Generated with Claude Code

[bctiemann]

@claude /review and limit response to areas of potential concern.

[github-actions]

Claude finished @bctiemann's task in 51s —— View job

---

Review: Fixes #587 — Use actual FK target column in migration 0011

• Read migration file
• Analyze diff for potential concerns

---

The fix is correct and minimal. Two areas worth flagging:

1. Multiple rows per constraint if composite FKs exist

The query joins information_schema.constraint_column_usage (which records referenced columns) with information_schema.key_column_usage (which records referencing columns) on constraint_name only — no column-position join. For a multi-column FK, this produces a cross-product of rows per constraint. The loop would then attempt to DROP/ADD the same constraint multiple times, and the second ADD CONSTRAINT would fail (the constraint name is the same on each iteration, and the first iteration already created it).

In practice this cannot occur today — all FKs on custom_objects_* tables are single-column — but it is a latent fragility if the plugin ever gains composite FK constraints.

Risk level: Low (no composite FKs exist or are planned), but worth documenting or guarding with a GROUP BY / DISTINCT ON if you want to future-proof it.

2. F-string SQL with DB-sourced identifiers

table_name, constraint_name, column_name, foreign_table, and the new foreign_column are all interpolated directly into f-string SQL at lines 69, 75, 77–83. The values originate from information_schema, so they're not attacker-controlled unless the database itself is already compromised — an acceptable risk in a migration context. The double-quote quoting ("{table_name}", etc.) also prevents most injection. Worth being aware of, but not a blocker.

---

No other concerns. The core logic change — pulling ccu.column_name instead of hardcoding "id" — is the right fix, and ccu is exactly the correct source for the referenced column name.