pg_get_viewdef() 返回空或报错主因是权限不足或对象不存在；需确认视图存在、指定schema、授予usage和select权限；依赖分析需结合pg_depend、pg_matviews、pg_foreign_table及正则解析sql文本。
查视图定义时 pg_get_viewdef() 返回空或报错
PostgreSQL 里直接查 pg_get_viewdef('view_name') 却拿不到定义，大概率是权限或对象不存在。这个函数默认只查当前 schema，且调用者必须对视图有 USAGE（schema 级）和 SELECT（视图级）权限。
- 先确认视图是否存在：
SELECT * FROM pg_views WHERE viewname = 'your_view'; - 跨 schema 要带 schema 名：
pg_get_viewdef('myschema.myview')，不加引号且大小写敏感 - 若仍报
permission denied，让 DBA 给你GRANT USAGE ON SCHEMA myschema TO your_user;和GRANT SELECT ON myschema.myview TO your_user;
依赖链断在物化视图或外部表上
用 pg_depend 或 pg_rewrite 查依赖时，物化视图（pg_matviews）和外部表（pg_foreign_table）不会出现在标准视图依赖树里——它们的依赖关系藏在 pg_class.relkind 的不同取值中，且外部表依赖可能指向 FOREIGN SERVER 而非本地表。
- 查完整依赖建议组合两个查询：
SELECT DISTINCT refobjid::regclass FROM pg_depend WHERE objid = 'myview'::regclass AND deptype = 'n';（基础依赖），再手动检查结果里是否有matview或foreign table - 物化视图需单独查
pg_matviews并用其definition字段展开；外部表则要顺藤摸到pg_foreign_server和对应 FDW 配置 - 别指望
pg_depend自动穿透 FDW —— 它只管元数据层，不解析远程 SQL
ERROR: relation "xxx" does not exist 出现在视图查询中
这个错误表面是表找不到，但实际常因视图定义里用了未加 schema 前缀的表名，而当前 search_path 又没包含该表所在 schema。PostgreSQL 解析视图定义时，用的是**创建时**的 search_path，不是执行时的。
- 用
SELECT pg_get_viewdef('myview', true);（第二个参数设为true）强制返回带 schema 的完整定义，一眼看出哪些表缺前缀 - 检查视图创建时的
search_path：SELECT pg_get_userbyid(datdba) FROM pg_database WHERE datname = current_database();配合SHOW search_path;回溯建视图的上下文 - 修复方法不是改
search_path，而是重建视图：用CREATE OR REPLACE VIEW ... AS SELECT ... FROM schema.table显式写全路径
递归查依赖时死循环或漏掉 CTE 和子查询
视图里嵌套了另一个视图，而那个视图又反过来引用了当前视图，pg_depend 不会标记这种循环依赖（deptype = 'i' 是内部依赖，不参与层级展开）。更麻烦的是，CTE（WITH 子句）和子查询里的表名根本不会进 pg_depend，它们只在运行时解析。
- 用
pg_get_viewdef()提取 SQL 文本后，正则匹配FROM\s+([a-z_][a-z0-9_]*\.)*[a-z_][a-z0-9_]*和JOIN\s+([a-z_][a-z0-9_]*\.)*[a-z_][a-z0-9_]*才能抓到 CTE 和子查询里的真实依赖 - 循环依赖得靠人工识别：把所有被引用的视图定义都拉出来，grep 彼此的名字
- 别信工具一键“分析依赖树”——它基本只处理
pg_depend能覆盖的那部分，而实际出错点往往在它看不见的地方
真正卡住你的，常常不是最外层视图，而是它某次嵌套里一个没加 schema 的表名，或者某个物化视图背后连着的已下线外部数据源。查的时候别只盯着 pg_depend，文本解析和权限验证得同步做。
