如何在PostgreSQL 16中创建带有安全限定符的SQL视图

PostgreSQL 16 中安全视图需三重保障：专用schema并回收public权限、所有表显式带schema前缀、视图创建后立即收回PUBLIC的SELECT权限；仅靠WHERE条件无法实现安全限定，必须结合RLS策略与SET LOCAL设置GUC变量。

PostgreSQL 16 不支持带参数的视图，所谓“安全限定符”不是语法特性，而是靠权限控制 + 显式过滤 + schema 显式引用共同实现的。直接写 CREATE VIEW 不足以保障安全，关键在后续三步：权限回收、schema 锁定、行级隔离。

为什么不能靠 WHERE 条件自动实现安全限定？

视图里的 WHERE user_id = current_user_id() 或 WHERE status = 'active' 只是查询逻辑，不构成访问控制。调用者仍可能：

• 通过 UNION ALL 或子查询绕过视图封装
• 用 EXPLAIN 看到底层表名，再直接查原表
• 若视图跨 schema 且未锁定 search_path，可能命中同名但非预期的表（比如 audit.users 被误查）

创建视图前必须做的三件事

缺一不可，否则“安全限定”形同虚设：

• 先建专用 schema（如 secure_views），并 REVOKE USAGE ON SCHEMA public FROM PUBLIC
• 确保视图中所有表都显式带 schema 前缀，例如 SELECT * FROM app.orders，而非 SELECT * FROM orders
• 创建视图后立即执行：REVOKE SELECT ON secure_views.active_users FROM PUBLIC，再按角色 GRANT SELECT

如何让视图真正只返回当前用户数据？

靠视图本身做不到，必须组合 RLS（行级安全策略）+ 视图封装：

• 在底层表（如 app.orders）上启用 RLS：ALTER TABLE app.orders ENABLE ROW LEVEL SECURITY
• 添加策略：CREATE POLICY user_orders_policy ON app.orders FOR SELECT USING (user_id = current_setting('app.user_id', TRUE)::INTEGER)
• 视图定义保持简洁：CREATE VIEW secure_views.my_orders AS SELECT * FROM app.orders
• 关键：调用前必须先 SET LOCAL app.user_id = '123'，且该 GUC 需在函数或应用层预设，不能依赖客户端随意设置

最容易被忽略的是 search_path 和 RLS 的配合——即使视图写了 app.orders，如果 RLS 策略里用了 current_setting 且没校验类型，或者没设 FORCE ROW LEVEL SECURITY，策略就可能被跳过。安全视图不是“写完就安全”，而是“每层都得卡死”。