如何在SQL中使用SESSION_USER函数识别当前执行用户-SQL-PHP中文网

SESSION_USER返回会话初始登录用户，不可被SET ROLE修改；PostgreSQL中等价于SESSION_USER()，SQL Server中为SESSION_USER（不带括号），用于审计登录来源而非执行上下文。

如何在sql中使用session_user函数识别当前执行用户

SESSION_USER 返回的是登录用户，不是执行上下文用户

在 PostgreSQL、SQL Server 等支持 SESSION_USER 的数据库中，它返回的是当前会话建立时认证的用户名，而非当前执行语句所处的角色（比如通过 SET ROLE 或 EXECUTE AS 切换后的角色）。这点常被误认为等同于 CURRENT_USER 或 USER，但语义不同。

常见错误现象：你用 admin 登录后执行 SET ROLE 'reporter'，再查 SESSION_USER，结果仍是 'admin' —— 这不是 bug，是设计如此。

SESSION_USER 是会话级只读标识，不可被 SET 修改
PostgreSQL 中它等价于 SESSION_USER() 函数调用（带括号也可，但不推荐）
SQL Server 中必须不带括号：SESSION_USER；带括号会报错 Invalid column name 'SESSION_USER'
MySQL 不支持 SESSION_USER，它只有 USER()（返回 user@host）和 CURRENT_USER()（返回授权匹配的 user@host）

在 WHERE 条件或视图中安全使用 SESSION_USER

想基于当前登录人动态过滤数据？比如只允许用户查看自己名下的订单。这时直接在视图定义里写 WHERE owner = SESSION_USER 是可行的，但要注意权限模型是否允许绕过。

示例（PostgreSQL）：

CREATE VIEW my_orders AS
SELECT * FROM orders
WHERE owner = SESSION_USER;

这个视图对所有用户都生效，且每次查询都会实时取当前会话的登录名。但注意：

如果 owner 字段是 TEXT 类型，而 SESSION_USER 返回值含大小写或空格，需统一处理，例如用 LOWER(SESSION_USER)
SQL Server 中该函数返回 sysname（即 nvarchar(128)），与字符串字段比较时建议显式转换，避免隐式转换失败
不能在索引表达式或物化视图（如 PostgreSQL 的 MATERIALIZED VIEW）中依赖 SESSION_USER，因为它不是稳定函数（volatile）

SESSION_USER vs CURRENT_USER：别混用权限判断逻辑

这是最容易踩坑的地方。如果你在存储过程里做权限校验，用错了函数会导致越权或误拒。

Browser Session Manager

使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能

下载

典型场景：DBA 创建了一个 audit_log 表，要求插入时记录操作者身份。用 SESSION_USER 记录的是谁连进来，而 CURRENT_USER 才反映当前执行语句的实际有效角色。

PostgreSQL 中：CURRENT_USER 可随 SET ROLE 改变；SESSION_USER 始终不变
SQL Server 中：CURRENT_USER 对应 USER_NAME()，SESSION_USER 对应 SYSTEM_USER（但二者通常相同，除非用了 EXECUTE AS）
若过程内有 EXECUTE AS 'otheruser'，则 CURRENT_USER 变，SESSION_USER 不变
审计类逻辑优先用 CURRENT_USER；登录来源追踪类逻辑才用 SESSION_USER

跨数据库移植时 SESSION_USER 的兼容性陷阱

写可移植 SQL 时，SESSION_USER 并非通用。Oracle 用 USER（等价于 CURRENT_USER），不支持 SESSION_USER；SQLite 完全不支持该函数。

如果你正在抽象一个用户感知的数据访问层，不要硬编码 SESSION_USER。更稳妥的做法是：

应用层显式传入当前登录用户名（作为参数或上下文变量）
数据库侧用 pg_backend_pid() + pg_stat_activity 查登录用户（PostgreSQL 专属，性能开销略高）
SQL Server 中可用 ORIGINAL_LOGIN() 替代部分 SESSION_USER 场景，尤其在 EXECUTE AS 后仍要追溯原始登录人时
避免在 DDL（如分区策略、行级安全策略 RLS）中强依赖该函数，因为不同版本/厂商实现差异大

真正需要区分“谁连进来”和“谁在执行”的时候，得先确认你的数据库版本是否把这两个概念暴露得足够清晰——否则很容易在权限收紧后才发现日志里全是 postgres 或 sa。