PostgreSQL 不支持直接创建递归视图，因其视图定义仅允许纯 SELECT 语句，禁止 WITH RECURSIVE；可通过 STABLE 函数封装递归逻辑或使用物化视图替代，但需注意防环、深度限制与索引优化。
PostgreSQL 不支持直接创建递归视图（CREATE VIEW ... WITH RECURSIVE），硬写会报错 ERROR: cannot use WITH in a view definition。这不是你语法写错了，而是内核限制——视图定义只接受纯 SELECT 语句，而 WITH RECURSIVE 属于查询表达式结构，不被允许作为视图顶层。
为什么不能直接 CREATE VIEW + WITH RECURSIVE
PostgreSQL 的视图本质是“保存的查询”，但解析器在构建视图元数据时，要求其主体必须是标准 SELECT（不含 CTE、WITH、UNION 等复合结构）。这和 MySQL 或 SQL Server 不同，是 PG 的语法设计决定的，不是版本问题。
强行尝试会出现两种典型错误：
-
ERROR: syntax error at or near "WITH"（语法提前拒绝） -
ERROR: cannot use WITH in a view definition（明确提示禁止）
用 STABLE 函数封装递归逻辑最实用
把递归查询写进函数，再让视图调用它，是最可控、最易维护的方式。关键点在于：
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 函数必须声明为
STABLE（不能是IMMUTABLE，因为结果依赖输入参数） - 返回类型要用
RETURNS TABLE(...)，字段名和类型必须与递归查询SELECT完全一致 - 参数用于传入起始节点，比如
start_id INTEGER - 视图本身只是简单包装：例如
CREATE VIEW v_org_tree AS SELECT * FROM get_subtree(1);
示例函数：
CREATE OR REPLACE FUNCTION get_subtree(start_id INTEGER)
RETURNS TABLE(id INTEGER, name TEXT, parent_id INTEGER, level INTEGER) AS $$
WITH RECURSIVE tree AS (
SELECT id, name, parent_id, 1 AS level
FROM org_units WHERE id = start_id
UNION ALL
SELECT u.id, u.name, u.parent_id, t.level + 1
FROM org_units u
JOIN tree t ON u.parent_id = t.id
)
SELECT * FROM tree;
$$ LANGUAGE SQL STABLE;物化视图可绕过限制但要接受延迟
如果你真需要类视图的语法 + 原生递归能力，且能容忍非实时数据，CREATE MATERIALIZED VIEW 是合法替代项——它允许 WITH RECURSIVE，因为它本质是一张物理表。
- 首次创建会执行递归查询并落盘，后续需手动
REFRESH MATERIALIZED VIEW - 适合层级变动不频繁的场景（如部门架构每月调整一次）
- 注意：刷新期间锁表，高并发写入时要避开窗口
- 无法参数化，每次只能固定起点；若需多起点，得建多个物化视图或改用函数
递归深度和循环风险必须显式控制
组织架构树可能意外成环（比如 A→B→C→A），或层级过深触发默认限制（max_recursive_iterations = 100）。实际使用中必须加防护：
- 在递归 CTE 中加入路径数组防环：
ARRAY[id] AS path，并在 JOIN 条件中加AND u.id != ALL(t.path) - 用
level <= 20之类硬限制防止爆炸式展开 - 查祖先链（向上递归）时，
parent_id IS NOT NULL是必要终止条件，漏掉就会无限循环 - 调试时先用小范围数据测试，别直接在生产表上跑无限制递归
真正麻烦的从来不是怎么写出递归语句，而是如何确保它在任意脏数据下不崩、不慢、不锁死——路径记录、深度截断、索引覆盖（parent_id 字段必须有 B-Tree 索引），这三样缺一不可。
