PostgreSQL 15中视图默认非只读，其可更新性取决于是否满足单表映射、包含完整主键或唯一约束列等规则，而非版本特性；需结合权限控制与运行时检查确保只读。
PostgreSQL 15 中的视图默认**不是只读的**，但是否“可更新”不取决于版本号，而取决于视图定义是否满足 PostgreSQL 的可更新性规则——CREATE VIEW 本身不加锁、不限制写入，只要结构合规，INSERT/UPDATE/DELETE 就可能穿透执行。
哪些视图能被 UPDATE/INSERT/DELETE？
PostgreSQL 判断一个视图是否可更新，核心看它是否满足“单表映射 + 无遮蔽关键列”的条件。不是语法开关，而是运行时检查。
-
pg_views.is_updatable字段为'YES'才表示该视图理论上可更新（注意：这只是元数据提示，不代表权限已开放） - 必须只从**一张基表** SELECT，不能有
JOIN、UNION、子查询、CTE（除非是简单非递归 CTE 且最终仍单表） - SELECT 列表中必须包含该基表的**完整主键或唯一约束列**（否则 PostgreSQL 无法定位行）
- 不能含：
GROUP BY、HAVING、DISTINCT、聚合函数（COUNT()、SUM()等）、窗口函数、OFFSET/LIMIT（影响行定位） - 不能对列做表达式计算（如
salary * 1.1），但允许别名（salary AS adjusted_salary）
如何验证视图是否真能被更新？
别信文档描述，直接查系统表或试操作。很多开发者写了看似简单的视图，却因隐式类型转换或索引缺失导致 is_updatable 为 'NO'。
- 查元数据：
SELECT table_name, is_updatable, is_insertable_into, is_trigger_updatable FROM information_schema.tables WHERE table_schema = 'public' AND table_name = 'your_view_name';
- 尝试执行
INSERT INTO your_view_name (...) VALUES (...)，观察错误：如果是ERROR: cannot insert into view，说明结构不满足；如果是permission denied，说明权限不足，而非不可更新 - 注意：即使
is_insertable_into = 'YES'，若用户没被显式授予INSERT权限，仍会报错
为什么 GRANT SELECT 不等于禁止 INSERT？
很多人误以为只给 SELECT 权限就安全了，其实完全相反：只要视图可更新、用户又有 INSERT 权限（哪怕来自 PUBLIC 角色），INSERT INTO view 就会直接改底层表。
-
GRANT SELECT ON VIEW v TO u;完全不阻止INSERT INTO v—— PostgreSQL 默认允许尝试，失败才报错 - 真正阻断写入，必须显式收回：
REVOKE INSERT, UPDATE, DELETE ON VIEW v FROM u; - 更稳妥的做法是：先
REVOKE ALL ON TABLE base_table FROM u;，再只授SELECT给视图，并确保视图定义本身不可更新（比如加WHERE false或聚合）
想强制只读？别依赖视图定义，靠权限和运行时控制
PostgreSQL 15 没有 CREATE READ ONLY VIEW 语法。所谓“只读视图”，本质是“用户无法写入的视图”，这靠的是组合策略，不是单条语句。
- 最简方案（适合临时用途）：
CREATE OR REPLACE VIEW v AS SELECT * FROM t WHERE FALSE;—— 因为不返回任何行，INSERT会因“no rows to update”失败，但依然会尝试执行，不推荐生产用 - 生产级做法：创建专用角色
readonly_role，设default_transaction_read_only = on，并REVOKE INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public FROM readonly_role - 如果必须暴露复杂逻辑，用
SECURITY DEFINER函数替代视图：CREATE FUNCTION fn_report() RETURNS TABLE(...) AS $$ SELECT ... $$ LANGUAGE sql SECURITY DEFINER;，然后REVOKE INSERT, UPDATE, DELETE ON FUNCTION fn_report() FROM PUBLIC;
真正麻烦的不是怎么写 CREATE VIEW，而是怎么让 DBA 和应用开发者对“可更新性”达成一致理解——视图结构、用户权限、事务级别设置三者必须协同，漏掉任意一层，所谓的“只读”就形同虚设。
