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被误查）
创建视图前必须做的三件事
缺一不可，否则“安全限定”形同虚设：
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 先建专用 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，策略就可能被跳过。安全视图不是“写完就安全”，而是“每层都得卡死”。
