不能用触发器实现“根据角色动态解密”，因其不响应SELECT，无法拦截查询返回值；真正可行的是视图结合CURRENT_SETTING()与CASE WHEN做运行时字段脱敏。
不能用触发器实现“根据角色动态解密”——这不是触发器该干的事，强行做会破坏事务语义、暴露密钥、且根本无法拦截 SELECT 返回值。
为什么 BEFORE/AFTER 触发器无法用于 SELECT 时的动态解密
PostgreSQL 触发器只响应 INSERT、UPDATE、DELETE（以及 TRUNCATE），不响应 SELECT。所谓“查询时按角色返回明文/密文”，触发器连介入的机会都没有。
常见错误现象：CREATE TRIGGER decrypt_on_select ... FOR SELECT ON users ... —— 这条语句直接报错，语法不合法。
真正需要的不是触发器，而是查询重写层或视图 + 会话上下文。触发器只适合在写入时做统一加密（如所有用户插入都用固定密钥 AES 加密），但做不到“张三查是明文、李四查是星号”。
可行路径：用 CURRENT_SETTING() + 视图做运行时字段脱敏
PostgreSQL 允许在视图中使用 CURRENT_SETTING('app.role', true) 获取会话变量，再配合 CASE WHEN 控制返回内容。这是目前最轻量、可审计、不依赖中间件的方案。
- 应用连接后必须先执行
SET app.role = 'analyst';（角色名由应用控制） - 视图定义里所有分支返回类型要一致，比如都转成
TEXT：CASE WHEN current_setting('app.role', true) = 'admin' THEN phone ELSE pgp_sym_decrypt(phone_enc, 'admin_key')::TEXT END -
pgp_sym_decrypt()要求字段本身是BYTEA类型（由pgp_sym_encrypt()写入），且密钥硬编码在视图里——这意味着 DBA 可看到密钥，不适合高敏场景 - 如果密钥需隔离，应把解密逻辑移到应用层，数据库只存密文；视图只做格式化（如
LEFT(phone,3) || '****' || RIGHT(phone,4)）
加密写入可用触发器，但密钥不能动态取自角色
你可以在 BEFORE INSERT OR UPDATE 触发器里对敏感字段做加密，但密钥必须是确定性值（如常量、表字段、或 CURRENT_USER 字符串哈希），不能调用 CURRENT_SETTING()——因为触发器执行时会话变量可能未设置，或事务内多次调用结果不一致，导致同一行加密结果不同，破坏数据一致性。
示例安全写法：
CREATE OR REPLACE FUNCTION encrypt_phone() RETURNS TRIGGER AS $$
BEGIN
IF NEW.phone IS NOT NULL THEN
NEW.phone_enc := pgp_sym_encrypt(NEW.phone, 'global_app_key');
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
注意：'global_app_key' 是写死的，不是从 current_setting 或 CURRENT_USER 拼接而来。否则会出现：同一事务中两次 UPDATE 同一行，因会话变量变化导致两次加密结果不同，后续无法解密。
真正需要角色级动态加解密？绕过 PostgreSQL 原生能力
原生 PostgreSQL 不支持“按登录角色自动加解密字段”。如果你的合规要求明确要求“DBA 看不到明文、且不同角色看到不同形态”，那么：
- 不要把密钥放进数据库或视图——哪怕只是字符串字面量
- 不要依赖
CURRENT_USER做密钥派生（前缀匹配易被伪造） - 优先考虑网关层方案，如
DBG 网关，它在协议层解析 SQL、识别字段、按策略重写，密钥由外部 KMS 托管，数据库只存密文 - 或者把解密彻底移出数据库，在应用层连接池初始化时根据
user属性加载对应密钥，查到密文后再本地解密
最容易被忽略的一点：所有基于会话变量（current_setting）的方案，都要求应用严格管理连接生命周期——不能复用连接、不能跨请求残留 SET 值，否则 A 用户的查询可能意外拿到 B 用户的脱敏规则。
