CURRENT_USER

Return the effective user name for the current session.

Syntax

CURRENT_USER()

Description

## Overview Returns the effective user name of the currently executing session. When role impersonation or SET ROLE is in effect, this reflects the assumed identity rather than the original authenticated user. Use CURRENT_USER for row-level security predicates, audit columns, and default values on created_by fields. CURRENT_USER and SESSION_USER return different values when role switching is active: CURRENT_USER follows the effective identity, SESSION_USER keeps the original login. ## Session context - The value is determined at session establishment and is updated by SET ROLE or equivalent impersonation commands. - Within a single statement, the value is stable. - Takes no arguments; both `CURRENT_USER` and `CURRENT_USER()` are accepted. - Never returns NULL in a properly authenticated session. ## Behavior - Always returns a non-NULL string. - Deterministic for the duration of the current role context. - Side effect free; no RPC is made at call time. ## Compatibility - Matches the SQL-standard CURRENT_USER and the PG-compat function of the same name.

Examples

-- Inspect the current effective user
SELECT CURRENT_USER();

-- Stamp audit columns on insert
INSERT INTO ops.audit.events (event_id, actor, occurred_at)
VALUES (UUID(), CURRENT_USER(), CURRENT_TIMESTAMP);

-- Compare CURRENT_USER to SESSION_USER to detect role escalation
SELECT CURRENT_USER() AS effective, SESSION_USER() AS logged_in;

-- Scope a row-level security predicate
SELECT * FROM hr.catalog.salaries
WHERE owner = CURRENT_USER();

-- Use in a default expression
-- (column definition, for context)
-- created_by STRING DEFAULT CURRENT_USER()

Pitfalls

• CURRENT_USER reflects the effective role. When a SET ROLE is in effect, it returns the assumed role, not the original authenticated login. Use SESSION_USER when you need the immutable login identity.
• Authorization decisions that rely on CURRENT_USER must also evaluate the column value under the same role context. If you cache results across sessions, stamp the cached row with the user at write time.
• The function is evaluated once per statement; it does not refresh mid-statement. A long-running statement that spans a role change sees the role that was effective at the start.
• CURRENT_USER and the current catalog/schema are orthogonal: switching schemas does not change the user.

See Also

• session_user
• current_schema
• current_catalog
• current_database