CURRENT_USER returns the name of the database role executing the statement.
CURRENT_USER is a session-level function that returns the name of the role currently executing the SQL statement. It is handy for auditing, row-level security, and conditional logic based on privileges.
Run SELECT CURRENT_USER;
. PostgreSQL (and Amazon Redshift) return the role name as a text value that you can embed in larger queries or functions.
CURRENT_USER is used as a zero-argument function or keyword in any SQL expression context:
-- Stand-alone call
SELECT CURRENT_USER;
-- In a SELECT list
SELECT id, name, CURRENT_USER AS executed_by FROM Customers;
-- In a WHERE clause
SELECT *
FROM Orders
WHERE created_by = CURRENT_USER;
Yes. Tie user context to business data by filtering, auditing, or enforcing visibility rules. For example, only show orders entered by the logged-in warehouse role.
Insert a new order while recording who executed it:
INSERT INTO Orders (customer_id, order_date, total_amount, created_by)
VALUES (42, CURRENT_DATE, 199.99, CURRENT_USER);
Store it in audit columns (created_by
, updated_by
) via triggers. Combine with SET ROLE
for test impersonation. Use row-level security to automatically filter rows to CURRENT_USER
.
CURRENT_USER reflects the active role, not the originally authenticated one. Use SESSION_USER if you need the login role.
CURRENT_USER is evaluated once per statement. Re-evaluate inside loops or dynamic SQL to avoid stale values.
Yes. Redshift inherits the PostgreSQL behavior, so SELECT CURRENT_USER;
returns the active database user.
CURRENT_USER returns name
type, automatically castable to text
; explicit casts are rarely needed but supported (CURRENT_USER::text
).
No. search_path changes schema resolution only; it has no impact on the value of CURRENT_USER.
Yes. USER is an ANSI-SQL alias for CURRENT_USER in PostgreSQL and Redshift.
Not directly. Use SET ROLE or SET SESSION AUTHORIZATION to switch roles; CURRENT_USER then reflects the new active role.