Table Editor Drops And Re-Adds Primary Key On Saves That Don'T Change It

The comparison logic uses column display order instead of column identity. When display order differs from the key's internal order (as in composite keys like (b,a) or after renames), the code sees a difference and attempts to rebuild the primary key. This is a design flaw in handling primary key comparison.

1. Open Supabase Studio Table Editor for a table with a composite primary key (e.g., (b, a)). 2. Modify an unrelated column property (e.g., description) or rename a column. 3. Save the changes. 4. Observe that the primary key is dropped and re-added, causing an error if foreign keys reference it, or silently changing the key order to (a, b).

This fix assumes column IDs are unique and stable. If the table editor ever changes column IDs (unlikely but possible during certain operations), the comparison could miss legitimate primary key changes. Additionally, if the primary key involves columns that are deleted and recreated with new IDs, the fix might not detect the change. To rollback safely, revert to the previous name-based comparison but ensure the comparison uses the primary key order as returned by the database, not display order. Test thoroughly with composite keys and foreign key dependencies.