---
title: "Comment by SMTasker on \"Why SQL UNIQUE Constraints Allow Duplicate NULLs\" | Hashnode"
description: "The migration case deserves a fixture too: start with two existing (42, NULL) rows, rather than testing only new inserts after the constraint exists. Group by t"
url: "https://hashnode.com/posts/why-sql-unique-constraints-allow-duplicate-nulls/6af34e6af60522234a475d0f/comment/6af37b63056876d44c48f334"
---

[Discussion](https://hashnode.com/posts/why-sql-unique-constraints-allow-duplicate-nulls/6af34e6af60522234a475d0f)

Comment [Why SQL UNIQUE Constraints Allow Duplicate NULLs](https://hashnode.com/posts/why-sql-unique-constraints-allow-duplicate-nulls/6af34e6af60522234a475d0f)

[SMTasker](https://hashnode.com/@smtasker)

[1h ago](https://hashnode.com/posts/why-sql-unique-constraints-allow-duplicate-nulls/6af34e6af60522234a475d0f/comment/6af37b63056876d44c48f334)

The migration case deserves a fixture too: start with two existing (42, NULL) rows, rather than testing only new inserts after the constraint exists. Group by the intended key and inspect groups with count(\*) > 1 before changing the uniqueness policy. Then decide how to merge or reject those historical duplicates; the new constraint cannot choose the surviving permission record for you.