PostgreSQL视图无法通过语法限制DML权限，必须结合基表权限与WITH CHECK OPTION实现只INSERT、禁DELETE：授予用户基表INSERT/SELECT权，拒授DELETE权，并创建带CHECK OPTION的单表可更新视图。
CREATE VIEW 本身无法实现“只允许 INSERT、禁止 DELETE”的权限隔离——PostgreSQL 视图的 DML 权限由底层表权限决定，不是视图语法控制的。
你真正要解决的问题是：让某个用户能往某组数据里加新记录，但不能删已有记录。这必须靠角色权限组合 + 视图定义协同实现，而不是单靠 CREATE VIEW。
INSERT 权限必须授予底层表，不是视图
-
GRANT INSERT ON TABLE t TO u才能让用户u向表t插入数据 -
GRANT INSERT ON VIEW v TO u没有意义：如果视图不可更新（比如含JOIN或GROUP BY），这条命令会报错；如果可更新，实际执行的是对基表的INSERT，权限检查仍落在基表上 - 所以：想让
INSERT INTO v成功，用户必须对视图所依赖的至少一张基表有INSERT权限；而DELETE FROM v是否成功，取决于用户是否对同一张基表有DELETE权限
常见错误现象：
- 用户能
INSERT INTO v，也能DELETE FROM v→ 说明他同时拥有基表的INSERT和DELETE权限 - 用户
INSERT INTO v报permission denied for table t→ 视图依赖表t，但没给他INSERT权限
可更新视图的条件限制了 INSERT 范围
PostgreSQL 默认只允许对满足以下条件的视图执行 INSERT（且穿透到底层表）：
-
FROM子句仅含一张表（或一个可更新视图） - 查询不含
DISTINCT、GROUP BY、HAVING、WINDOW、UNION等 - 所有列都直接来自基表，无表达式或常量
- 基表主键列完整出现在视图 SELECT 列表中（否则
UPDATE/DELETE可能失败，但INSERT有时仍可工作）
这意味着：
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 如果你建了一个带
WHERE status = 'pending'的视图，用户INSERT进来的行可能不满足该条件，导致后续查不到——这不是权限问题，而是逻辑一致性问题 - 若需强制插入数据符合视图逻辑，必须加
WITH CHECK OPTION（见下一条）
WITH CHECK OPTION 是防止“插入后不可见”的关键
它不控制权限，但能拦截非法 INSERT / UPDATE：
-
CREATE VIEW v AS SELECT * FROM t WHERE status = 'pending' WITH CHECK OPTION; - 用户执行
INSERT INTO v VALUES (..., 'done');会直接报错：new row violates check option for view "v" -
LOCAL CHECK OPTION：只校验当前视图的WHERE条件 -
CASCADED CHECK OPTION：还会校验所有底层视图的条件（适合嵌套视图）
注意：
-
WITH CHECK OPTION对DELETE无效——它只管写入和修改是否“还在视图里”，不管删除 - 要禁
DELETE，唯一办法是不给用户基表的DELETE权限
实操建议：用最小权限角色 + 单表可更新视图 + WITH CHECK OPTION
假设你有一张订单表 orders，只想让客服角色只能插入状态为 'new' 的订单，不能删：
-- 1. 创建专用角色 CREATE ROLE support_role; -- 2. 只给 SELECT + INSERT，不给 UPDATE/DELETE GRANT SELECT, INSERT ON TABLE orders TO support_role; -- 3. 创建带校验的视图（确保插入的数据能被看到） CREATE VIEW orders_new_only AS SELECT * FROM orders WHERE status = 'new' WITH CHECK OPTION;
然后让客服用户属于 support_role。此时：
-
INSERT INTO orders_new_only (...) VALUES (...);✅ 成功（只要status = 'new'） -
INSERT INTO orders_new_only (...) VALUES (..., 'processed');❌ 报错（违反CHECK OPTION） -
DELETE FROM orders_new_only WHERE id = 1;❌ 报错（用户无DELETE权限） -
SELECT * FROM orders_new_only;✅ 正常
真正的难点不在语法，而在权限模型的分层设计：视图只是“查询入口”，DML 权限永远绑定到物理表。漏掉任何一层（比如忘了 revoke DELETE，或误授了基表 UPDATE），整个只读/只插策略就失效。
