Summary
rewriteEncryptedAlterColumns (packages/cli/src/commands/db/rewrite-migrations.ts) is hardcoded to the v2 type eql_v2_encrypted. The EQL v3 domains (eql_v3_text_search, eql_v3_integer_ord, …) have no equivalent rewriter, so a Drizzle v3 user who changes a column's type through drizzle-kit generate/push gets an un-runnable migration with nothing to fix it.
Why it happens
drizzle-kit's ALTER COLUMN path wraps a customType's dataType() return in double-quotes and prepends "{typeSchema}".. Custom types have no typeSchema, so the emitted SQL is:
ALTER TABLE "t" ALTER COLUMN "c" SET DATA TYPE "undefined"."eql_v3_text_search";
which Postgres rejects. This is the same failure the v2 surface hits — v2 solves it by rewriting the broken ALTER COLUMN into an ADD COLUMN + backfill-comment + DROP + RENAME sequence (and, separately, because there's no implicit cast from text/numeric to the encrypted type). See ALTER_COLUMN_TO_ENCRYPTED_RE and renderSafeAlter in rewrite-migrations.ts.
The v3 CREATE TABLE path is already correct (fixed in #688: dataType() emits the bare eql_v3_* name, which resolves via search_path). This issue is only about the ALTER COLUMN path.
Repro
- Define a Drizzle table with a plaintext column, generate/apply a migration.
- Change that column to an
eql_v3_* domain (e.g. types.TextSearch(...) via makeEqlV3Column).
drizzle-kit generate → the migration contains SET DATA TYPE "undefined"."eql_v3_text_search".- Applying it fails.
Fix sketch
Generalize rewriteEncryptedAlterColumns to also match the eql_v3_* domain family (and their "undefined".-prepended / pre-quoted mangled forms), reusing the same ADD/DROP/RENAME rewrite, fully-qualifying the replacement type as "public"."eql_v3_<domain>" (the rewriter controls the whole string, so full qualification is valid there). Note the v3 cast story differs from v2 — v3 columns store the encrypted jsonb envelope, so confirm whether the backfill-comment guidance needs adjusting for the v3 flow.
Context
Found while addressing the schema-qualification review notes on #688 (rc.2 M5). Not a regression from #688 — a pre-existing gap the v3 work surfaced.
Summary
rewriteEncryptedAlterColumns(packages/cli/src/commands/db/rewrite-migrations.ts) is hardcoded to the v2 typeeql_v2_encrypted. The EQL v3 domains (eql_v3_text_search,eql_v3_integer_ord, …) have no equivalent rewriter, so a Drizzle v3 user who changes a column's type throughdrizzle-kit generate/pushgets an un-runnable migration with nothing to fix it.Why it happens
drizzle-kit's ALTER COLUMN path wraps a
customType'sdataType()return in double-quotes and prepends"{typeSchema}".. Custom types have notypeSchema, so the emitted SQL is:which Postgres rejects. This is the same failure the v2 surface hits — v2 solves it by rewriting the broken
ALTER COLUMNinto anADD COLUMN+ backfill-comment +DROP+RENAMEsequence (and, separately, because there's no implicit cast fromtext/numericto the encrypted type). SeeALTER_COLUMN_TO_ENCRYPTED_REandrenderSafeAlterinrewrite-migrations.ts.The v3 CREATE TABLE path is already correct (fixed in #688:
dataType()emits the bareeql_v3_*name, which resolves viasearch_path). This issue is only about the ALTER COLUMN path.Repro
eql_v3_*domain (e.g.types.TextSearch(...)viamakeEqlV3Column).drizzle-kit generate→ the migration containsSET DATA TYPE "undefined"."eql_v3_text_search".Fix sketch
Generalize
rewriteEncryptedAlterColumnsto also match theeql_v3_*domain family (and their"undefined".-prepended / pre-quoted mangled forms), reusing the sameADD/DROP/RENAMErewrite, fully-qualifying the replacement type as"public"."eql_v3_<domain>"(the rewriter controls the whole string, so full qualification is valid there). Note the v3 cast story differs from v2 — v3 columns store the encrypted jsonb envelope, so confirm whether the backfill-comment guidance needs adjusting for the v3 flow.Context
Found while addressing the schema-qualification review notes on #688 (rc.2 M5). Not a regression from #688 — a pre-existing gap the v3 work surfaced.