应过滤 pg_depend 中 deptype = ‘n’、refclassid = ‘pg_class’::regclass、objid != refobjid 且 refobjid > 16384 的行，排除物化视图及系统对象，并用递归 cte 补全多层嵌套依赖路径。
查视图依赖关系时 pg_depend 返回结果太多，怎么过滤出真正影响当前视图的上游表？
postgresql 的 pg_depend 是底层依赖记录，它包含函数、默认值、规则、视图定义等所有依赖类型，直接查会混入大量无关项。真正影响视图逻辑的，只有类型为 'n'（normal）且 refclassid = 'pg_class'::regclass 的行，并且得排除掉视图自身（objid != refobjid）和系统对象（refobjid > 16384）。
- 先用
pg_get_viewdef()看实际定义，确认是否含子查询或 CTE，这类结构不会出现在pg_depend中，得人工识别 - 再查
pg_depend时加条件：deptype = 'n' AND classid = 'pg_class'::regclass AND refclassid = 'pg_class'::regclass - 注意：物化视图依赖也走同一张表，但其刷新逻辑不触发级联失效，别误判为“强依赖”
ALTER table … DROP column 导致视图失效却没报错，为什么？
PostgreSQL 默认对视图做 lazy binding：创建时不校验列是否存在，只在执行 select 时才检查。所以删底层表字段后，视图仍能 CREATE VIEW 成功，但首次查询抛出 Error: column … does not exist。
- 视图定义里若用
*或未限定字段名（如写name而非t1.name），删列后几乎必挂 -
pg_views.definition存的是原始 SQL 字符串，没法自动重写字段引用，也没法推导别名覆盖 - 想提前发现，得手动跑
SELECT * FROM pg_views WHERE definition ~ 'your_table_name';，再逐个EXPLAIN验证
嵌套视图层级超过 3 层后，pg_depend 查不出完整路径
PostgreSQL 的依赖追踪只记录直接依赖，不递归展开。A → B → C 这种链路中，pg_depend 有 A→B 和 B→C，但没有 A→C。想还原全链，得自己写递归 CTE 或脚本遍历。
- 递归查询要小心循环依赖（比如 A 引用 B，B 又通过 C 绕回 A），必须加
depth限制和path数组去重 -
pg_depend.deptype = 'i'（internal）是内部生成的依赖，比如规则系统插入的隐式依赖，不能忽略，否则链路断裂 - 实际维护中，超过 2 层嵌套的视图建议拆成物化视图或临时表，否则改一个底层字段，得从底往上逐层验证
mysql 和 SQL Server 的视图依赖检测比 PostgreSQL 更“实”，但代价是什么？
MySQL 5.7+ 用 INFORMATION_SCHEMA.VIEW_TABLE_USAGE 记录显式引用，SQL Server 有 sys.dm_exec_describe_first_result_set 做运行前解析——它们都更早暴露问题，但代价是：
- MySQL 每次
CREATE VIEW都会尝试解析所有引用对象，如果目标表被锁或不存在，直接失败 - SQL Server 对视图做 schema binding（
WITH SCHEMABINDING）后，底层表字段不能删、不能改类型，灵活性大幅下降 - PostgreSQL 的“懒校验”看似松散，反而让灰度发布、字段灰度下线成为可能；只是把验证时机从建视图挪到了查视图
依赖不是越早报错越好，而是要看你愿不愿意为“提前发现”支付开发节奏变慢、变更流程变重的代价。真正在意稳定性的团队，往往宁可多写几行 psql -c "SELECT pg_get_viewdef('v_name')" 手动扫一遍，也不愿被 schema binding 卡住上线。