PostgreSQL中可更新视图必须同时满足单表查询、无聚合/distinct/group by、列均为基表直接引用、主键完整暴露等内核级条件，且用户须对底层表拥有对应DML权限；真正只读需角色隔离+default_transaction_read_only+全面REVOKE写权限。
可更新视图的硬性条件：不是语法问题，是定义边界
PostgreSQL 15 中 CREATE VIEW 本身不决定是否可更新——能否 INSERT/UPDATE/DELETE 视图，完全取决于视图定义是否满足内核级约束。不满足就直接报错，不会静默失败。
必须同时满足以下全部条件，视图才可能被 PostgreSQL 自动识别为可更新（即 pg_views.is_updatable = 'YES'）：
- 只查询单个基表（不能有
JOIN、UNION、子查询、CTE） - 不含聚合函数（
COUNT()、SUM()等）、DISTINCT、GROUP BY、HAVING - 所有列都是基表列的直接引用（不能是表达式，如
price * 1.1 AS new_price） - 基表的主键或唯一约束列必须完整出现在视图列中（否则无法定位行）
- 不能包含
WITH CHECK OPTION以外的限制性子句（该选项本身不影响可更新性，但影响写入校验）
验证方式：SELECT is_insertable_into FROM pg_views WHERE viewname = 'your_view_name'; 返回 'YES' 才表示 PostgreSQL 认为它可插入。
为什么你写的简单视图仍被拒绝更新？权限和角色设置才是关键
即使视图定义满足全部条件，UPDATE your_view SET ... 仍可能报 ERROR: permission denied for table xxx 或静默失败——这不是视图问题，是权限链断裂。
PostgreSQL 的可更新视图依赖「用户对底层表有 DML 权限」，而不仅仅是视图上的 GRANT SELECT：
-
GRANT SELECT ON VIEW v TO u;不自动授予对基表的INSERT/UPDATE权限 - 如果用户
u没有对基表的UPDATE权限，哪怕视图可更新，执行也会失败 - 更隐蔽的情况：用户通过
INHERIT继承了某个角色的SELECT，但没继承UPDATE，同样会卡住
检查方法：\z your_base_table（在 psql 中）看当前用户是否列在 UPDATE 权限栏；修复用：GRANT UPDATE ON TABLE base_table TO u;
多表连接视图想更新？别碰 INSTEAD OF 触发器，除非你准备好写事务逻辑
像 SELECT u.name, o.status FROM users u JOIN orders o ON u.id = o.user_id 这类视图，PostgreSQL 默认不可更新，且 INSTEAD OF 触发器是唯一原生支持路径——但它不是“开关”，而是“重写入口”。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
你必须手动处理每种操作的语义，且极易出错：
-
INSTEAD OF INSERT触发器里要自己判断：是插用户？还是插订单？还是两者都插？字段映射是否覆盖 NULL 边界？ -
INSTEAD OF UPDATE必须能从:NEW和:OLD唯一还原出哪张表哪一行要改，漏掉主键字段就会批量误更新 - 跨表操作必须显式加
BEGIN ... EXCEPTION事务块，否则部分成功会导致数据不一致 - 触发器无法自动感知外键约束变化，基表加了新
NOT NULL字段后，触发器体若没同步更新，就会在运行时报错
示例陷阱：UPDATE v SET name = 'Alice' WHERE id = 123; 在连接视图中，若触发器没检查 :NEW.name 是否非空，又没给 users.name 设默认值，就会因违反 NOT NULL 失败。
真正安全的“只读视图”根本不是靠视图定义，而是靠角色隔离
如果你本意是“让用户只能查不能改”，不要寄希望于“让视图不可更新”——因为只要用户对底层表有权限，他就能绕过视图直接改表。真正的只读必须从角色层面切断所有写入口。
PostgreSQL 15 中最稳妥的做法是组合使用：
- 创建无登录能力的角色：
CREATE ROLE readonly_role WITH NOLOGIN; - 强制事务只读：
ALTER ROLE readonly_role SET default_transaction_read_only = on; - 只授最小权限：
GRANT USAGE ON SCHEMA public TO readonly_role;+GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_role; - 撤回所有写权限：
REVOKE INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public FROM readonly_role; - 对新增对象自动生效：
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly_role;
这个方案下，哪怕视图技术上可更新，用户执行 INSERT INTO v 也会立刻报 ERROR: cannot execute INSERT in a read-only transaction——错误发生在事务层，而非视图解析层，无法绕过。
容易被忽略的是：default_transaction_read_only 是会话级设置，但只有在角色创建时用 ALTER ROLE ... SET 才能固化为连接默认行为；如果只是在会话里 SET，下次连接就失效。
