Postgres migrations should not trigger if the unique key is too long

[parsonsmatt]

A table with a long uniqueness key will trigger a migration, but Postgres will silently truncate it to the original length. persistent-postgresql's migrations should truncate the name of a constraint before checking if it needs to be renamed.

[MaxGabriel]

With foreign keys, it was possible to match the names Postgres auto-generates #996

IIRC for uniqueness constraints, Persistent's DB generated name is based off the Haskell name (eg UniqueOrganizationPaymentAuthorizationControlsOrganizationId), not what database table/column names are (eg organization_id.

I think because of this, Persistent could just do a simple truncation to the max length, rather than trying to match the auto-generated names like we do for FKs

(Not 100% on all of this, working from memory)

[Vlix]

I recently checked this to explain to a new employee, and yes, the Haskell name you define will be turned into lower-snake-case and used as the uniqueness constraint name. So if there's a max length, the TH could just throw an exception and/or it could be auto-truncated (but I'd imagine that might lead to conflicts with the Haskell names being different, but the truncated ones overlapping in Postgres)