[lakhansamani]

What this is

It started as "add a CockroachDB test". The test did not pass, and neither did
the next two engines I pointed it at. Four of the SQL backends in the supported
list could not create their own schema, and one more was rewriting four tables
on every single restart.

Backend	On main	After this PR
PostgreSQL / Yugabyte	boots, but AutoMigrate rewrites 4 tables under ACCESS EXCLUSIVE on every restart	boots; 5 one-time ALTERs on the upgrade boot, 0 on every boot after
CockroachDB	boots once, then never starts again (ALTER COLUMN TYPE is experimental, SQLSTATE XCEXF); legacy-unique cleanup silently does nothing	boots and re-boots clean; cleanup actually drops the constraints
MySQL / MariaDB	never worked. CREATE TABLE fails (Error 1170), then DROP CONSTRAINT fails (1091), then DeleteSessionTokensByUserID fails (1064)	fresh install and v1 upgrade both green, 0 DDL after first boot
SQL Server	broken since 2.3.0-rc.10. CREATE UNIQUE INDEX on an nvarchar(MAX) column is rejected outright	schema creates; fresh install and both data-bearing upgrade paths green, 0 DDL after. 2 upsert tests still red — separate driver bug, see below
SQLite / LibSQL	fine	unchanged, still green
PlanetScale	same MySQL-wire code path as MySQL	same fixes apply; hosted, not run here

The five defects

1. char(36) churns forever on Postgres, and is fatal on CockroachDB.
GORM's postgres driver reads these columns back from information_schema as
bpchar, which never prefix-matches the declared char(36), so AutoMigrate
re-emits the same no-op type change on every boot:

ALTER TABLE "authorizer_sessions" ALTER COLUMN "user_id" TYPE char(36) USING "user_id"::char(36)

On PostgreSQL that is a silent table rewrite under ACCESS EXCLUSIVE on four
tables at every restart. On CockroachDB it is fatal — ALTER COLUMN TYPE sits
behind an experimental flag. Five non-PK columns move to varchar(36), which is
what the catalog reports; values are 36-char uuids either way.

2. CockroachDB reports unique indexes as unique constraints.
GORM then issues DROP CONSTRAINT "uni_<table>_<column>" — a name it only ever
creates from a unique tag — for every gorm:"uniqueIndex" field, and startup
dies on constraint ... does not exist (SQLSTATE 42704). Fixed by wrapping the
dialector and skipping the drop when the model declares the index.

3. CockroachDB cannot ALTER TABLE ... DROP CONSTRAINT a UNIQUE.
unimplemented: ... use DROP INDEX CASCADE instead (SQLSTATE 0A000). Without
this the v1 legacy-uniqueness cleanup silently no-ops, leaving UNIQUE on
authorizer_otps.phone_number — where v2 writes '' for every email OTP, so
the second one is rejected.

4. MySQL and MariaDB, three separate aborts.
GORM's mysql driver sizes an unsized string to varchar(191) when the field
carries index or unique — but it checks only those two tags, so a
uniqueIndex field becomes longtext and MySQL refuses the table:
Error 1170: BLOB/TEXT column 'client_id' used in key specification without a key length. Then COLUMN_KEY='UNI' triggers the same phantom drop as (2)
(Error 1091). Then ESCAPE '\' in DeleteSessionTokensByUserID is
Error 1064 — MySQL does not accept a backslash escape character there, so the
escape char is now ! and the LIKE escaping is portable.

5. SQL Server, the same sizing gap as MySQL.
Identical two-tag check, nvarchar(MAX) instead of longtext:

mssql: Column 'client_id' in table 'authorizer_clients' is of a type that is
invalid for use as a key column in an index.

Fixed the same way, at the driver's own width (256). No MigrateColumnUnique
override needed — SQL Server reads uniqueness from
INFORMATION_SCHEMA.TABLE_CONSTRAINTS, which lists real constraints only, so
catalog and models agree as on PostgreSQL.

Backward compatibility

Each dialector embeds the driver's concrete Dialector/Migrator, not the
gorm.Dialector/gorm.Migrator interface, so every method the driver defines —
including the optional ones GORM type-asserts — stays promoted. That detail is
load-bearing: the first version of the CockroachDB wrapper embedded the
interface and panicked the moment a table with an index was created, because
migrator.BuildIndexOptionsInterface is asserted without an ok-check
(migrator.go:272, :822). It only showed up when MySQL was actually run. The
shared helper's doc comment records this so the next backend does not repeat it.

Postgres, Yugabyte, SQLite and LibSQL keep their existing gorm.Open paths
untouched.

	Fresh install	Upgrade from char(36)	Per-boot churn	Data integrity
PostgreSQL 18	suite green, 0 ALTERs	exactly 5 ALTERs, then 0	0 DDL, measured with log_statement=all	'' → length 0, short-id → 8, uuids → 36; byte-identical
CockroachDB v24.3	make test-cockroachdb PASS	boots and re-boots	0 DDL	—
MySQL 8.0.40	suite green	legacy char(36) + seeded authorizer_users_email_key / uq_otps_phone migrate in one boot	0 ALTER TABLE authorizer_* across 3 boots	rows intact; two phone_number='' OTPs now insertable
MariaDB 11	suite green	—	—	—
SQL Server 2022	schema creates; 2 known-red upserts	v1-shaped and 2.0.0–2.3.0 schemas each upgrade in one boot; both legacy UNIQUEs dropped	0 DDL on the next 2 boots	legacy@example.com joins on a 36-char user_id; otp_rows = 2; seeded authenticator row intact with the composite index built over the widened column
SQLite / LibSQL	green, incl. a legacy char(36) test.db	no-op	—	—

The MySQL varchar(191) width and the SQL Server nvarchar(256) width only
touch columns in tables that do not exist in v1 (clients, organizations,
org_memberships, federated_identities, scim_endpoints, trusted_issuers,
webauthn_credentials), so nothing is narrowed under existing data.

Known limitations

• SQL Server upserts. gorm.io/driver/sqlserver's MergeCreate builds its
  MERGE predicate from the primary key and ignores
  clause.OnConflict.Columns, so AddAuthenticator (keyed on
  (user_id, method)) and AddVerificationRequest (keyed on
  (email, identifier)) insert a second row instead of replacing one and hit
  the unique index. Two tests red. It is a write-path driver bug, unrelated to
  migration, and belongs in its own PR — so make test-sqlserver exists but is
  not in test-all-db.
• SQL Server debris. 2.3.0-rc.10 is where the unsized uniqueIndex
  columns and the composite index over authenticators.user_id both landed, so
  the two never coexist in a database that booted. A database touched by a
  2.3.0-rc.10 or later SQL Server boot has user_id as char(36) inside
  that index, and SQL Server will not retype an indexed column — drop it before
  upgrading; no boot there ever finished, so it holds no data. Databases from
  2.0.0 through 2.3.0 did boot, carry no index over any widened column, and are
  verified above to upgrade with rows intact.
• GetIndexes is not support on the sqlserver driver, so step 2 of the
  legacy cleanup (standalone unique indexes on email/phone_number) is a
  no-op there. Pre-existing; the constraint form, which is what v1 created, is
  still cleaned.
• PlanetScale is hosted MySQL-wire and was not run; it shares the MySQL code
  path verbatim.
• Yugabyte is unchanged — same postgres.Open path, same bpchar catalog —
  and was not run.

Also in here

• make test-cockroachdb, test-mysql, test-mariadb, test-sqlserver and
  their cleanup targets; test-all-db now covers 12 DBs. Every one of them was
  executed, not just make -n'd: make test-sqlserver boots the container,
  creates the database, runs the whole repo suite (integration tests included)
  and ends with exactly the two upserts above red and nothing else.
• scripts/wait-for-sql.sh, because nc -z lies on Docker Desktop: it connects
  to the published-port proxy the instant docker run -p returns. MySQL binds
  3306, runs its init scripts and then restarts — mysqladmin ping answers
  during that window, so the probe runs a real query against authorizer_test
  instead. This produced one spurious FAIL before it was fixed; ready time went
  6s → 11s.
• TestDeleteUserCascadesAllUserOwnedRows failed on any second run against a
  persistent DB (fixed fixtures, no cleanup). Pre-existing — it fails
  identically on Postgres on main — now rerunnable.
• A metacharacter case on testAnchoredSessionTokenDelete, which is what the
  ESCAPE change needs to be pinned by.