oracle 19c中视图内用current_user或user无法实现动态行级权限控制，因其在视图创建时静态求值；必须通过dbms_rls绑定rls策略到基表，由策略函数返回动态where条件才能生效。
Oracle 19c 中不能靠视图里写 CURRENT_USER 或 USER 实现可靠的行级权限控制——它会被静态展开，等效于常量过滤，无法随登录用户动态生效。
为什么视图 WHERE 里写 USER 或 sys_context('userenv','session_user') 很容易失效
Oracle 视图定义是编译时解析的，USER 和 sys_context() 在视图创建阶段就被求值（通常是定义者账号），不是每次查询时重算。即使你用 WITH CHECK OPTION，也只约束 DML，不改变 SELECT 的行过滤逻辑。
常见错误现象：
- 用 DBA 账号创建视图后，所有用户查到的都是 DBA 自己的数据
- 应用层切换用户后，视图返回结果不变
- 执行
EXPLAIN PLAN发现过滤条件没下推到基表扫描，走了全表扫描再 filter
真正起作用的前提是：必须启用 Oracle 的细粒度访问控制（FGAC），即基于 DBMS_RLS 的策略（RLS），而不是依赖视图封装。
必须用 DBMS_RLS.ADD_POLICY 绑定策略到基表
视图只是查询入口，权限逻辑必须落在底层表上。策略函数返回的 WHERE 条件会在优化器阶段注入，且能利用索引。
实操要点：
- 策略函数必须返回
VARCHAR2类型的合法 SQL 片段，如'owner_id = sys_context(''userenv'', ''session_user'')' - 函数不能有副作用（不能 INSERT/UPDATE/COMMIT），否则策略启用后查询会报错
- 调用
DBMS_RLS.ADD_POLICY时，Object_Name必须是真实表名，不是视图名 - 策略默认对
SELECT生效；若需控制INSERT/UPDATE/DELETE，需显式指定Statement_Types并设Update_Check => TRUE
示例策略函数：
CREATE OR REPLACE FUNCTION fn_rls_order_filter(p_schema VARCHAR2, p_obj VARCHAR2)
RETURN VARCHAR2
AS
BEGIN
RETURN 'created_by = SYS_CONTEXT(''USERENV'', ''SESSION_USER'')';
END;
绑定策略：
BEGIN
DBMS_RLS.ADD_POLICY(
object_schema => 'app',
object_name => 'orders',
policy_name => 'order_rls_policy',
function_schema => 'app',
policy_function => 'fn_rls_order_filter',
statement_types => 'SELECT'
);
END;
视图仍可存在，但仅作字段投影或 JOIN 封装
启用 RLS 后，视图可以简化为纯结构包装，不再承担权限逻辑：
- 去掉所有
WHERE过滤，避免和 RLS 冲突或重复计算 - 可加
WITH READ ONLY防止误更新（RLS 不自动限制 DML） - 若业务需要多租户隔离（非 DB 用户维度），改用
sys_context('userenv', 'client_identifier')，由应用在连接后执行DBMS_SESSION.SET_IDENTIFIER设置
例如：
CREATE VIEW my_orders AS SELECT order_id, product_name, amount FROM app.orders WITH READ ONLY;
容易被忽略的权限与配置细节
RLS 策略生效的前提不是“建完就完事”，而是几个关键点环环相扣：
- 执行
DBMS_RLS.ADD_POLICY的用户必须有EXECUTE ANY PROCEDURE和目标表的ALTER权限 - 普通用户查视图前，必须已被授予基表的
SELECT权限（哪怕只是通过角色）；否则会报ORA-01031: insufficient privileges，而非无数据 - 如果使用
CLIENT_IDENTIFIER，应用必须在每次获取连接后主动设置，且连接池要支持传递该上下文（如 UCP、HikariCP 需配置oracle.jdbc.fanEnabled=false等） - 策略启用后，
SELECT * FROM orders和SELECT * FROM my_orders返回结果一致——说明 RLS 已接管，视图没额外逻辑
真正复杂的地方不在写策略函数，而在于权限链路是否完整、上下文是否被正确传递、以及是否误把视图当成了权限边界。一旦漏掉其中一环，看起来像生效了，实际形同虚设。
