ORA-04045、circular view dependency等错误在CREATE VIEW时即被拦截，因数据库解析依赖图检测到环；须用pg_depend过滤deptype='n'追踪显式依赖链，抽离共用逻辑为物化视图或表来切断循环。
ORA-04045、ERROR: circular view dependency 或 ERROR: infinite recursion 这类错误不是运行时报的，而是你执行 CREATE VIEW 或 CREATE OR REPLACE VIEW 时就被拦下来了——PostgreSQL 在解析依赖图阶段就拒绝入库。根本没机会“跑起来再看”。
查循环依赖必须用 pg_depend + deptype = 'n'
pg_depend 是唯一能反映视图间显式引用关系的系统表，但默认会混入大量系统自动生成的依赖（如 deptype = 'a'）。只关注 deptype = 'n' 才代表你写的 FROM v2 这种人为依赖。
常见误操作是直接查 SELECT * FROM pg_depend WHERE refobjid = 'v1'::regclass，结果看到一堆无关条目。正确写法是：
SELECT DISTINCT refobjid::regclass AS dependent_on, objid::regclass AS depends_on FROM pg_depend WHERE objid = 'v1'::regclass AND deptype = 'n' AND refobjid != objid;
拿到结果后，对每个 dependent_on 视图重复查，手动或用递归 CTE 构建依赖链。一旦发现某条路径终点又回到起点，就是循环。
别碰 WITH RECURSIVE 来绕开跨视图循环
WITH RECURSIVE 只解决单个视图内部的自引用（比如组织树向上查父级），它不改变视图定义之间的依赖关系。你写 CREATE VIEW v1 AS WITH RECURSIVE ... SELECT * FROM v2，而 v2 又 SELECT * FROM v1，PostgreSQL 依然报 circular view dependency。
试图用函数包装、延迟计算、或加条件判断（如 WHERE false）来“骗过”解析器，全部无效——内核在语法树构建阶段就检测环，不执行任何逻辑。
- 删掉中间视图，把两层 SQL 合成一个查，是最快速验证是否真需要拆分的办法
- 如果业务上必须保留抽象层级，把共用逻辑抽成物化视图（
CREATE MATERIALIZED VIEW）或普通表，用定时任务刷新，彻底切断视图间引用
字段名冲突会让错误看起来像循环依赖
两个基础视图都SELECT id, created_at，上层视图 JOIN 它们后没加别名，PostgreSQL 报 column "id" specified more than once。这容易被误判为依赖问题，其实是语义歧义：数据库无法确定你后续想引用哪边的 id。
这类错误常出现在嵌套较深的视图里，尤其当你用 SELECT * 时——源表加字段、重命名列，都会让上层视图崩，且错误位置和真实原因脱节。
- 所有
JOIN后的字段必须显式别名，例如u.id AS user_id,o.id AS order_id - 禁止在视图定义中使用
SELECT *，哪怕源表结构“很稳定” - 如果只是为简化
JOIN，考虑改用 SQL 函数（CREATE FUNCTION ... RETURNS TABLE），字段名由调用方控制，更灵活
PostgREST 的 400/500 错误其实暴露的是底层循环
PostgREST 遇到42P17（infinite recursion）会返回 500，但它只是把 PostgreSQL 的原生错误透传出来。这意味着你的视图已经在 DB 层面被认定为非法，不是 PostgREST 配置问题。
调试时不要先去翻 PostgREST 日志，直接连 psql 执行 SELECT * FROM your_view LIMIT 0 —— 这条语句只走元数据解析，能立刻触发依赖检查，比等 API 调用失败更快定位。
真正麻烦的是那种“看似没循环”的间接引用：v1 → v2 → v3 → v1，或者通过函数、规则、触发器间接引入。这种必须靠完整依赖链追踪，不能只看一层 pg_depend 输出。
