PostgreSQL触发器不能实现SQL Server式的字段级过滤，因其仅响应INSERT/UPDATE/DELETE行级事件，不介入SELECT执行流程；真正可行的是视图+条件表达式（如CASE结合current_setting）实现动态字段脱敏。
PostgreSQL 触发器不能实现 SQL Server 那种“字段级过滤”语义——即在 SELECT 时自动隐藏或脱敏某些字段值。这不是功能缺失，而是设计定位根本不同。
WHEN 子句只对行级 DML 生效，不参与查询过滤
SQL Server 的“字段级过滤”常指动态数据脱敏（DDM）或行/列安全策略（RCLS），它在查询执行前重写计划、注入表达式或替换值。PostgreSQL 的 WHEN 子句完全不介入 SELECT 流程：它只在 INSERT/UPDATE/DELETE 的行级触发阶段做布尔判断，且仅用于决定“这一行是否进触发器函数”。
-
WHEN必须配合FOR EACH ROW，不能用于语句级或SELECT -
WHEN (OLD.salary IS DISTINCT FROM NEW.salary)这类写法只影响 UPDATE 是否调用触发器函数，和 SELECT 返回什么字段无关 - 试图在
AFTER SELECT ON users上建触发器？语法直接报错：ERROR: event trigger "xxx" is not supported for SELECT
想隐藏/脱敏字段？用视图 + 条件表达式替代
真正接近“字段级过滤”的做法，是把敏感字段逻辑封装进视图，并用会话变量或角色控制输出。例如：
CREATE VIEW users_safe AS
SELECT id, name,
CASE WHEN current_setting('app.show_salary', true)::text = 'true'
THEN salary
ELSE NULL END AS salary,
created_at
FROM users;
这样应用只需 SET app.show_salary = 'true'，就能控制字段可见性。比触发器更轻量、可测试、无副作用。
- 避免在触发器里用
RAISE EXCEPTION拦截 SELECT——根本不会触发 - 不要试图在
BEFORE INSERT中修改NEW.salary来“过滤输入值”，这是数据清洗，不是查询过滤 - 若需审计谁查了敏感字段，可用事件触发器（
event_trigger）监听table_rewrite或日志，但无法阻止或改写结果
字段变更监控 ≠ 字段过滤，别混淆用途
如果你实际想要的是“当某字段被更新时才执行动作”，这才是 WHEN 的正确场景：
CREATE TRIGGER log_email_change AFTER UPDATE OF email ON users FOR EACH ROW WHEN (OLD.email IS DISTINCT FROM NEW.email) EXECUTE FUNCTION log_field_change();
注意两个关键点：
-
UPDATE OF email是触发前提（语句必须含email列） -
WHEN (OLD.email IS DISTINCT FROM NEW.email)是二次筛选（值真变了才进函数） - 两者缺一不可：只写
WHEN不写UPDATE OF，哪怕只改了name，只要满足条件也会触发——可能误伤
最易忽略的一点：所有所谓“字段级控制”，在 PostgreSQL 中必须分清是 DML 时的约束/填充（用触发器），还是查询时的呈现/权限（用视图、RLS、列权限）。混用会导致行为不可预测，比如给 salary 列设 GRANT SELECT ON COLUMN 后，再在触发器里做脱敏，就纯属多余。
