视图不支持动态策略函数，须用函数内联+条件下推实现行列级过滤；PostgreSQL需STABLE函数及会话变量，SQL Server用RLS，MySQL依赖应用层或HeatWave；须撤基表权限、授视图权限并确保函数可执行。
视图本身不支持动态策略函数，必须用函数内联 + 条件下推
SQL 标准视图（CREATE VIEW）是静态定义的，无法在运行时根据当前用户、角色或上下文动态调用策略函数（比如 current_user() 或自定义的 is_allowed_to_see_salary()）。想实现“行列级双重过滤”，本质是把策略逻辑写进视图定义里，并确保它能被查询优化器下推——否则过滤会发生在应用层或全表扫描后，失去安全意义。
常见错误是直接在视图里写 WHERE is_sensitive_policy(user_id) 却没确认该函数是否标为 STABLE 或 IMMUTABLE，导致 PostgreSQL 拒绝下推，MySQL 8.0+ 则可能完全不识别函数式谓词。
- PostgreSQL：策略函数必须声明为
STABLE，且不能含事务级状态（如pg_backend_pid()）；推荐用current_setting('app.user_role', true)配合SET app.user_role = 'analyst'传参 - SQL Server：改用行级安全（RLS）策略，视图仅做列裁剪；RLS 的谓词函数可引用
SESSION_CONTEXT(N'user_role') - MySQL 8.0+：不支持函数式视图过滤，只能靠
PREVILEGE+ 列权限 + 应用层 WHERE 拼接（不推荐），或升级到 HeatWave 的数据屏蔽能力
行列双控必须拆成两层：视图裁列 + 策略函数控行
试图在一个视图里既 SELECT name, dept 又用 WHERE is_row_visible(id) 是可行的，但“双控”真正起效的前提是：列裁剪不破坏行过滤的语义，且策略函数返回布尔值、不暴露原始字段。
典型陷阱是策略函数里直接引用敏感列（如 RETURN salary > 5000 AND current_user() = owner），这会导致执行计划无法跳过读取 salary 字段，违反列级隔离原则。
- 正确做法：策略函数只依赖非敏感字段（如
dept_id,tenant_id,user_role）和会话变量 - 视图定义中显式排除敏感列：
SELECT id, name, dept_name FROM employees WHERE is_row_accessible(dept_id) - 若需按用户动态展/隐列（如 HR 可见
hire_date，普通员工不可见），必须用动态 SQL 或应用层控制，纯视图做不到
策略函数性能差？检查是否触发了全表扫描
当视图加了策略函数后查询变慢，大概率是优化器放弃下推，改为对基表全扫再过滤。验证方式很简单：对视图执行 EXPLAIN (ANALYZE)，看实际扫描行数是否等于基表总行数。
根本原因常是策略函数用了不可下推的操作：
- 调用了未标记
STABLE的自定义函数（PostgreSQL） - 函数体含子查询或
EXECUTE IMMEDIATE（Oracle/MySQL） - WHERE 中混用策略函数和非 SARGable 表达式，如
UPPER(name) = UPPER(is_row_accessible())
修复建议：把策略逻辑尽量简化为等值判断或范围比较；用 pg_stat_statements 查看该视图对应的真实执行计划是否命中索引。
别忽略权限链路：视图所有权 ≠ 策略生效权
即使视图定义里写了 WHERE is_row_accessible()，如果用户对基表有直接 SELECT 权限，就能绕过视图、直查原表。策略函数只有在视图路径上才被调用。
- 必须收回用户对基表的权限：
REVOKE SELECT ON employees FROM analyst_role - 只授视图权限：
GRANT SELECT ON v_employee_public TO analyst_role - PostgreSQL 还需确保策略函数对目标角色可执行：
GRANT EXECUTE ON FUNCTION is_row_accessible(int) TO analyst_role
最易被忽略的一点：策略函数若依赖 current_setting()，而应用没在连接初设置好上下文（如忘记 SET app.user_id = '123'），函数会返回 NULL 或默认 FALSE，导致查不到任何数据——不是没生效，是策略条件恒假。
