SET ROLE

|            SET ROLE            |                       |            |                  |                                           |
|:------------------------------:|-----------------------|------------|------------------|-------------------------------------------|
|[Prev](sql-set-constraints.html)|[Up](sql-commands.html)|SQL Commands|[Home](index.html)| [Next](sql-set-session-authorization.html)|

---

[]()

## SET ROLE

SET ROLE — set the current user identifier of the current session

## Synopsis

```
SET [ SESSION | LOCAL ] ROLE role_name
SET [ SESSION | LOCAL ] ROLE NONE
RESET ROLE

```

## Description

 This command sets the current user identifier of the current SQL session to be *`role_name`*. The role name can be written as either an identifier or a string literal. After `SET ROLE`, permissions checking for SQL commands is carried out as though the named role were the one that had logged in originally.

 The specified *`role_name`* must be a role that the current session user is a member of. (If the session user is a superuser, any role can be selected.)

 The `SESSION` and `LOCAL` modifiers act the same as for the regular [`SET`](sql-set.html) command.

`SET ROLE NONE` sets the current user identifier to the current session user identifier, as returned by `session_user`. `RESET ROLE` sets the current user identifier to the connection-time setting specified by the [command-line options](libpq-connect.html#LIBPQ-CONNECT-OPTIONS), [`ALTER ROLE`](sql-alterrole.html), or [`ALTER DATABASE`](sql-alterdatabase.html), if any such settings exist. Otherwise, `RESET ROLE` sets the current user identifier to the current session user identifier. These forms can be executed by any user.

## Notes

 Using this command, it is possible to either add privileges or restrict one's privileges. If the session user role has the `INHERIT` attribute, then it automatically has all the privileges of every role that it could `SET ROLE` to; in this case `SET ROLE` effectively drops all the privileges assigned directly to the session user and to the other roles it is a member of, leaving only the privileges available to the named role. On the other hand, if the session user role has the `NOINHERIT` attribute, `SET ROLE` drops the privileges assigned directly to the session user and instead acquires the privileges available to the named role.

 In particular, when a superuser chooses to `SET ROLE` to a non-superuser role, they lose their superuser privileges.

`SET ROLE` has effects comparable to [`SET SESSION AUTHORIZATION`](sql-set-session-authorization.html), but the privilege checks involved are quite different. Also, `SET SESSION AUTHORIZATION` determines which roles are allowable for later `SET ROLE` commands, whereas changing roles with `SET ROLE` does not change the set of roles allowed to a later `SET ROLE`.

`SET ROLE` does not process session variables as specified by the role's [`ALTER ROLE`](sql-alterrole.html) settings; this only happens during login.

`SET ROLE` cannot be used within a `SECURITY DEFINER` function.

## Examples

```
SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | peter

SET ROLE 'paul';

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | paul

```

## Compatibility

PostgreSQL allows identifier syntax (`"*`rolename`*"`), while the SQL standard requires the role name to be written as a string literal. SQL does not allow this command during a transaction; PostgreSQL does not make this restriction because there is no reason to. The `SESSION` and `LOCAL` modifiers are a PostgreSQL extension, as is the `RESET` syntax.

## See Also

[SET SESSION AUTHORIZATION](sql-set-session-authorization.html)

---

|[Prev](sql-set-constraints.html)|[Up](sql-commands.html)| [Next](sql-set-session-authorization.html)|
|:-------------------------------|:---------------------:|------------------------------------------:|
|        SET CONSTRAINTS         |  [Home](index.html)   |         SET SESSION AUTHORIZATION         |

 // \<![CDATA[ \<-- For SVG support if ('WebSocket' in window) { (function() { function refreshCSS() { var sheets = [].slice.call(document.getElementsByTagName("link")); var head = document.getElementsByTagName("head")[0]; for (var i = 0; i \< sheets.length; ++i) { var elem = sheets[i]; head.removeChild(elem); var rel = elem.rel; if (elem.href && typeof rel != "string" || rel.length == 0 || rel.toLowerCase() == "stylesheet") { var url = elem.href.replace(/(&|\\?)\_cacheOverride=\\d+/, ''); elem.href = url + (url.indexOf('?') \>= 0 ? '&' : '?') + '\_cacheOverride=' + (new Date().valueOf()); } head.appendChild(elem); } } var protocol = window.location.protocol === 'http:' ? 'ws://' : 'wss://'; var address = protocol + window.location.host + window.location.pathname + '/ws'; var socket = new WebSocket(address); socket.onmessage = function(msg) { if (msg.data == 'reload') window.location.reload(); else if (msg.data == 'refreshcss') refreshCSS(); }; console.log('Live reload enabled.'); })(); } // ]]\>