reference/sql/SET-ROLE.html.md.erb

---
title: SET ROLE
---

Sets the current role identifier of the current session.

## <a id="topic1__section2"></a>Synopsis

``` pre
SET [SESSION | LOCAL] ROLE <rolename>
SET [SESSION | LOCAL] ROLE NONE
RESET ROLE
```

## <a id="topic1__section3"></a>Description

This command sets the current role identifier of the current SQL-session context to be \<rolename\>. The role name may 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 \<rolename\> 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 `NONE` and `RESET` forms reset the current role identifier to be the current session role identifier. These forms may be executed by any user.

## <a id="topic1__section4"></a>Parameters

<dt>SESSION  </dt>
<dd>Specifies that the command takes effect for the current session. This is the default.</dd>

<dt>LOCAL  </dt>
<dd>Specifies that the command takes effect for only the current transaction. After `COMMIT` or `ROLLBACK`, the session-level setting takes effect again. Note that `SET LOCAL` will appear to have no effect if it is executed outside of a transaction.</dd>

<dt> \<rolename\>   </dt>
<dd>The name of a role to use for permissions checking in this session.</dd>

<dt>NONE  
RESET  </dt>
<dd>Reset the current role identifier to be the current session role identifier (that of the role used to log in).</dd>

## <a id="topic1__section5"></a>Notes

Using this command, it is possible to either add privileges or restrict privileges. If the session user role has the `INHERITS` 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 `NOINHERITS` 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, she loses her superuser privileges.

`SET ROLE` has effects comparable to `SET SESSION AUTHORIZATION`, 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`.

## <a id="topic1__section6"></a>Examples

``` sql
SELECT SESSION_USER, CURRENT_USER;
```
``` pre
 session_user | current_user 
--------------+--------------
 peter        | peter
```
``` sql
SET ROLE 'paul';
SELECT SESSION_USER, CURRENT_USER;
```
``` pre
 session_user | current_user 
--------------+--------------
 peter        | paul
```

## <a id="topic1__section7"></a>Compatibility

HAWQ 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; HAWQ does not make this restriction. The `SESSION` and `LOCAL` modifiers are a HAWQ extension, as is the `RESET` syntax.

## <a id="topic1__section8"></a>See Also

[SET SESSION AUTHORIZATION](SET-SESSION-AUTHORIZATION.html)