# X_MIGRATION_VIEW_DEPENDS

## Means

a view is compiled against a column this migration retypes

## Typical cause

`As of 2026-08-25`: a **preflight**, run inside each migration's own transaction before its first statement, in both `x db migrate` and `x db rollback`. A view stores a compiled parse tree, not its text, so `alter table … alter column … type` under a dependent view is `0A000 cannot alter type of a column used by a view or rule` and rolls the WHOLE migration back. The generator cannot see this by construction — a view is on no `SchemaDescription`, `introspect()` excludes views, and no entity can declare one — so the check lives where a connection exists. Until this code, the failure reached an operator as `X_DB_UNAVAILABLE: cannot reach the database` on a database the migrator was mid-transaction on, with the server's own `rule _RETURN on view … depends on column` sitting unread in a `DETAIL` field

## Fix

`cause` names the view, the table and the column; `fix` is a runnable pair of `psql "$DATABASE_URL" -c '…'` invocations — drop the view, then `x db migrate`, then re-create it from the `create view` the fix line carries verbatim, read out of `pg_get_viewdef` before the drop. Single-quoted deliberately: `identifier()` writes the view name in DOUBLE quotes, so the `-c "…"` form the sibling migration errors use would end the shell word at the name. A view whose name `identifier()` refuses (a quote, a space, a backslash — all legal inside a quoted Postgres name) gets a fix that names the view as JSON and asks you to quote it, rather than a `fix:` that throws

[Entity and database](/error-codes#entity-and-database)