SET SESSION AUSQLR-ZLanguage StatemenSET(SESSION-AUTHORIZATION(l)
NAME
SET SESSION AUTHORIZATION - set the session user identifier
and the current user identifier of the current session
SYNOPSIS
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION username
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT
RESET SESSION AUTHORIZATION
DESCRIPTION
This command sets the session user identifier and the
current user identifier of the current SQL-session context
to be username. The user name may be written as either an
identifier or a string literal. The session user identifier
is valid for the duration of a connection; for example, it
is possible to temporarily become an unprivileged user and
later switch back to become a superuser.
The session user identifier is initially set to be the
(possibly authenticated) user name provided by the client.
The current user identifier is normally equal to the session
user identifier, but may change temporarily in the context
of ``setuid'' functions and similar mechanisms. The current
user identifier is relevant for permission checking.
The session user identifier may be changed only if the
initial session user (the authenticated user) had the
superuser privilege. Otherwise, the command is accepted only
if it specifies the authenticated user name.
The SESSION and LOCAL modifiers act the same as for the
regular SET [set(l)] command.
The DEFAULT and RESET forms reset the session and current
user identifiers to be the originally authenticated user
name. These forms are always accepted.
EXAMPLES
SELECT SESSION_USER, CURRENT_USER;
current_user | session_user
--------------+--------------
peter | peter
SET SESSION AUTHORIZATION 'paul';
SELECT SESSION_USER, CURRENT_USER;
current_user | session_user
--------------+--------------
paul | paul
Page 1 (printed 3/24/03)
SET SESSION AUSQLR-ZLanguage StatemenSET(SESSION-AUTHORIZATION(l)
COMPATIBILITY
SQL99
SQL99 allows some other expressions to appear in place of
the literal username which are not important in practice.
PostgreSQL allows identifier syntax ("username"), which SQL
does not. SQL does not allow this command during a
transaction; PostgreSQL does not make this restriction
because there is no reason to. The privileges necessary to
execute this command are left implementation-defined by the
standard.
Page 2 (printed 3/24/03)
