And you probably don’t want to do that either because IIRC the sort of “get or insert” semantics you would need to implement an upsert are literally impossible to achieve in Postgres outside of SERIALIZABLE. And even then I don’t believe it would be atomic (some transactions would just have to be retried).
(You can materialize the conflict onto another row/lock. I find this approach rather cursed, but I’ve had to do it in some cases - not upserts though, why fight the platform)
Is there any particular reason you are avoiding a constraint?
