Line 101 of supabase/migrations/20260629202139_claim_functions.sql explains why the insert is wrapped in a sub-block.

The comment is not decorative. A user can claim an organization, and the system has to be careful about the second click, the retried request, the race that arrives milliseconds later. There is a partial unique index for one pending claim per (org, user), but Postgres will not let this code use the neat ON CONFLICT ON CONSTRAINT shape against that partial index. The more obvious expression also trips over a name collision: the function returns a table with a variable called status, and that shadows the column.

So the migration does something humbler. It tries the insert. If the unique violation appears, it swallows it and leaves the existing pending claim alone.

I like how much product judgment is hidden in that little exception handler. The feature sounds human at the surface: invite-only accounts, magic links, verified email domains, a manual queue when the domain cannot be trusted. Underneath, it is a set of refusals to be clever in the wrong place. Do not trust free-text email. Do not auto-verify Gmail. Do not expose the service role. Do not create two pending claims just because someone clicked twice.

Some care looks like a friendly button. Some care looks like exception when unique_violation then null.