There are various objections to expanding the conventional, up-tight, as-God-intended "one man, one woman" notion of marriage but by far the least plainly bigoted ones I am aware of are the bureaucratic ones.

To be blunt, the systems aren't set up to handle it. The paper forms have a space for the husband's name and a space for the wife's name. Married people carefully enter their details in block capitals and post the forms off to depressed paper-pushers who then type that information into software front-ends whose forms are laid out and named in precisely the same fashion. And then they hit "submit" and the information is filed away electronically in databases which simply keel over or belch integrity errors when presented with something so profound as a man and another man who love each other enough to want to file joint tax returns.

[...] Believe it or not, this is actually a fractionally less stupid database schema.

• males
  • id
  • forename
  • surname
  • birthdate
  • wife_id (unique foreign key references column females.id, may be NULL if male is unmarried)
• females
  • id
  • forename
  • surname
  • birthdate

This reduces the scope for ambiguity but it has suddenly become eye-poppingly sexist. Plus, what if you want to store information pertaining to the marriage itself? Like, the date it began?

Keep reading as he explains why you can't marry yourself, expands his database schema to cover polygamy, and eventually intransitive marriages:

The legal ramifications of what I'm about to describe are unguessable. I have no idea what rights a civil union like the ones which would be possible below would have, nor do I have any idea what kind of transhuman universe would require so complex a system. This is the marriage database schema to take us up to the thirty-first century, people.

Previously.