Ultimate

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

Listed under Entity and database

This page as markdown