SESSION_USER is a system-supplied identifier defined in the SQL Standard. When referenced in a query it yields the authorization identifier (username) that originally authenticated the current session, regardless of role changes or SET ROLE commands that may occur later in the transaction. It is evaluated once at connection time and remains constant until the session ends. Unlike CURRENT_USER, which can change when roles are set, SESSION_USER remains the original login name, making it useful for auditing or row-level security rules that must track the true originator of the session.In most engines SESSION_USER is exposed as a parameterless scalar function or reserved keyword that can be selected like any other column. Because it does not access user tables, it is fast and deterministic. However, its exact output format can differ:- PostgreSQL and SQL Server return just the user/role name.- MySQL returns user@host.- Case sensitivity follows the rules of the underlying catalog.If the connection uses OS authentication, SESSION_USER will equal the mapped database principal. In pooled connections the value reflects the identity supplied when the pool slot was created.
CURRENT_USER, CURRENT_ROLE, SYSTEM_USER, USER, CURRENT_SCHEMA
SQL-92
No. SESSION_USER is fixed when the connection is established and never changes within that session, even if the effective role changes.
CURRENT_USER can change when you run SET ROLE or EXECUTE AS; SESSION_USER always shows the original login. Use SESSION_USER for auditing the true originator.
Most major engines support it directly except Oracle and SQLite. In Oracle call SYS_CONTEXT('USERENV','SESSION_USER'). SQLite has no concept of users.
MySQL returns user_name@host_name, so you may need SUBSTRING_INDEX() or LIKE comparisons to isolate just the username.