必须按依赖顺序重建视图：先用pg_depend递归查出deptype='n'的用户级视图依赖链，再按拓扑序（从无依赖的叶子节点到底层向上）执行create or replace view；删列、改名列、类型变更等均需显式重写select列表，并手动恢复grant和comment。
不能直接改，必须按依赖顺序重建。PostgreSQL 的 CREATE OR REPLACE VIEW 不会自动处理嵌套依赖，旧视图列一变，上层视图立刻报 column does not exist。
先查清依赖链，别靠猜
pg_depend 是唯一可信来源，其他系统表（如 pg_views 或 INFORMATION_SCHEMA.VIEWS）只存定义文本，不反映真实引用关系。必须用递归 CTE 过滤出用户级视图依赖：
- 只保留
deptype = 'n'（normal dependency），排除系统自动生成的'a'（auto）、'i'（internal）类型 - 限定
classid = 'pg_class'::regclass且refclassid = 'pg_class'::regclass，确保只查视图/表之间引用 -
refobjid指被依赖对象（比如你要改的底层视图），objid指当前依赖者（上层视图）
示例查询（查 v_base 被哪些视图引用）：
WITH RECURSIVE deps AS (
SELECT objid, refobjid, deptype
FROM pg_depend
WHERE refobjid = 'v_base'::regclass AND deptype = 'n'
AND classid = 'pg_class'::regclass
AND refclassid = 'pg_class'::regclass
UNION ALL
SELECT d.objid, d.refobjid, d.deptype
FROM pg_depend d
INNER JOIN deps ON d.refobjid = deps.objid
AND d.deptype = 'n'
AND d.classid = 'pg_class'::regclass
AND d.refclassid = 'pg_class'::regclass
)
SELECT c.relname AS dependent_view
FROM pg_class c
JOIN deps ON c.oid = deps.objid;
按拓扑顺序重建，从底往上
重建不是按字母顺序跑 SQL，而是要严格遵循“无依赖 → 有依赖”的层级。否则 CREATE VIEW v_agg AS SELECT * FROM v_base 会因 v_base 尚未就绪而失败。
- 先找出所有
refobjid不在pg_depend.objid中的视图（即叶子节点，无依赖） - 对中间层视图计算依赖深度（
level），确保v_base（level 0）→v_agg（level 1）→v_report（level 2）顺序执行 - 每个视图都用
CREATE OR REPLACE VIEW，避免重复执行时报错；但注意它不会保留原COMMENT ON VIEW或GRANT
改定义时绕不开的三个硬约束
PostgreSQL 对视图结构变更极其保守，以下操作无法靠 CREATE OR REPLACE VIEW 隐式兼容：
- 删列或改列名：会直接触发
ERROR: cannot drop columns from view或cannot change name of view column，必须显式重写整个SELECT列表 - 中间插入新列：哪怕只是加一个
COALESCE(new_col, old_col) AS user_name，也必须保证所有列位置、类型、别名与上层视图期望一致 - 类型不匹配：比如底层把
price NUMERIC(10,2)改成price TEXT，上层视图若没显式CAST(price AS TEXT)，查询时可能隐式转换失败或静默截断
权限和注释得手动补，没人替你记
CREATE OR REPLACE VIEW 后，原有 GRANT SELECT ON v_base TO app_user 全部丢失，不是继承也不是保留——是清空。同样，COMMENT ON VIEW v_base IS 'legacy user mapping' 也不会留存。
- 执行前务必导出权限：
pg_dump --schema-only -t v_base --no-owner yourdb | grep -A5 'GRANT\|COMMENT' - 重建后逐条重授：
GRANT SELECT ON v_base TO app_user，再补注释：COMMENT ON VIEW v_base IS 'migrated to new schema with status mapping' - 特别注意：如果视图所有者不是当前执行用户，
GRANT可能被拒绝，需切换到视图 owner 角色下操作
最易被忽略的是字段契约——哪怕你把 user_name 改成 full_name，所有硬编码该字段名的下游代码（包括 ORM 映射、BI 工具字段绑定、ETL 脚本）都会在运行时才暴露错误，且无编译期提示。
