Improve Foreign Key Constraint Error UX in Table Editor

Summary

When attempting to delete a row in the Supabase Table Editor that is referenced by foreign key constraints, the current experience surfaces a generic error message. This makes it difficult for developers to understand why the deletion failed and what actions are required to resolve it.

This feature request proposes enhancing the error UI to:

• Clearly list all referencing tables and affected rows
• Provide actionable insights
• Generate a ready-to-run SQL query to resolve the constraint issue

---

Problem

Currently, when a user tries to delete a row that is referenced by a foreign key:

update or delete on table "users" violates foreign key constraint "orders_user_id_fkey" on table "orders"

Issues with current UX:

• ❌ Does not show all dependent tables (only one constraint at a time)
• ❌ No visibility into how many rows are affected
• ❌ Requires manual investigation across tables
• ❌ Slows down debugging and development workflows

---

Proposed Solution

Enhance the Table Editor delete flow to surface a structured and actionable error modal.

Example UX

⚠️ Cannot delete this row due to foreign key constraints

This row is referenced by:
- orders → 12 rows
- payments → 3 rows

Total affected rows: 15

Suggested Actions

• View related rows in each table
• Copy or run a generated SQL query to resolve dependencies

---

Generated SQL (Example)

Provide a ready-to-use SQL query that resolves the constraint by deleting dependent rows in the correct order:

DELETE FROM payments WHERE user_id = 1;
DELETE FROM orders WHERE user_id = 1;
DELETE FROM users WHERE id = 1;

Note: This query is generated for developer convenience and should be explicitly reviewed before execution.

---

Why This Matters

• Improves developer experience (DX)
• Reduces friction during debugging and testing
• Makes relational dependencies more transparent
• Aligns with Supabase's goal of making Postgres more accessible without abstracting it away

---

Scope (Initial Version)

This proposal focuses only on:

• Enhancing error visibility
• Providing dependency insights
• Generating SQL suggestions

Out of scope for now:

• Automatic cascade deletion
• Schema modifications (e.g., adding ON DELETE CASCADE)

---

Open Questions

• Should SQL execution be allowed directly from the modal, or only copy-to-clipboard?
• How should we handle deeply nested or circular dependencies?
• Should row counts be exact or estimated for performance reasons?

---

Willing to Contribute

I’d be happy to work on this feature and collaborate on the implementation if it aligns with the project direction.

---