mirror of
https://github.com/supabase/supabase.git
synced 2026-10-16 06:39:09 +03:00
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Bug fix ## What is the current behavior? Fixes #51574 Deleting several selected rows from a table with a composite primary key builds one `IN` list per key column: ```sql delete from public.user_roles where user_id in (1,2) and role_id in ('admin','viewer'); ``` That matches the cartesian product of the selected values, so rows the user never selected are deleted too. In the example above, selecting `(1, 'admin')` and `(2, 'viewer')` also deletes `(1, 'viewer')` and `(2, 'admin')`. ## What is the new behavior? When there is more than one primary-key column, the delete uses the tuple `IN` filter that pg-meta already supports: ```sql delete from public.user_roles where (user_id, role_id) in ((1, 'admin'), (2, 'viewer')); ``` Single-column primary keys keep the same SQL as before. The batched operation queue uses the same helper for its delete operations, so it is covered as well. Added unit tests for both the single and composite cases. ## Additional context This is silent data loss on join tables, which are the most common place for composite keys and for multi-row deletes.