Although "a random" can duplicate its previous values, "my random(s)" (which are created for this application purpose) cannot be duplicated when it's stored in the database as "live active data". I understand, that UNIQUE constraint is precisely the RDBMS tool to guarantee that.
From my perspective the issue is, you are using a 'unique' key generator that you know is not creating unique keys and then asking the database to make it right. Sort of like making a square peg fit a round hole by shaving the corners. It is possible but has sort of a messy feel to it.
Hmmm, yes.
Yet, I don't feel guilty as much, since that is quite similar to a unique key on database "username", while the "generator" (human mind) does not guarantee that. The DB just makes sure it does.
I think the argument to be made here is you have no control over what people choose as a username, you do have control over what your key generator outputs.
[--------------]
So an UPSERT is just one feature of ON CONFLICT. The other being DO NOTHING. Therefore I could see an argument made for adding other ON CONFLICT clauses. How difficult/plausible that would be is above my level of expertise.
Mine too. But I'd say that the above wording exactly makes the point I was trying to make. Thank you.