Description

Cette commande positionne l'identifiant utilisateur courant suivant la session SQL en cours à nom_rôle. Le nom du rôle peut être un identifiant ou une chaîne littérale. Après SET ROLE, la vérification des droits sur les commandes SQL est identique à ce qu'elle serait si le rôle nommé s'était lui-même connecté.

L'utilisateur actuel de la session doit avoir l'option SET pour l'utilisateur nom_rôle indiqué, soit directement soit indirectement via une chaîne d'appartenance ayant l'option SET. (Si l'utilisateur de la session est superutilisateur, tous les rôles sont utilisables.)

Les modificateurs SESSION et LOCAL agissent de la même façon que pour la commande SET.

SET ROLE NONE initialise l'identifiant utilisateur courant avec l'identifiant de la session en cours, tel qu'il est renvoyé par session_user. RESET ROLE initialise l'identifiant de l'utilisateur courant avec le paramètre à la connexion indiqué par les options en ligne de commande, ALTER ROLE ou ALTER DATABASE, si de tels paramètres existent. Sinon, RESET ROLE initialise l'identifiant utilisateur courant avec l'identifiant utilisateur courant. Ces formats peuvent être exécutés par tout utilisateur.

Notes

L'utilisation de cette commande permet d'étendre ou de restreindre les privilèges d'un utilisateur. Si le rôle de la session s'est vu donné des membres avec WITH INHERIT TRUE, il a automatiquement tous les droits de chacun de ces rôles. Dans ce cas, SET ROLE a pour effet de supprimer tous les droits sauf ceux que le rôle cible possède direcement ou hérite. D'un autre côté, si le rôle de la session s'est vu donné des membres avec WITH INHERIT FALSE, les droits des rôles donnés ne peuvent pas être utilisés par défaut. Néanmoins, si le rôle a été donné avec WITH SET TRUE, l'utilisateur de la session peut utiliser SET ROLE pour supprimer les droits affecttés directement à l'utilisateur de la session et acquérir à la place les droits du rôle nommé. Si le rôle a été donné avec WITH INHERIT FALSE, SET FALSE, alors les droits de ce rôle ne peuvent pas être utilisés, que ce soit avec ou sans SET ROLE.

Notez que, quand un utilisateur choisit un rôle autre que superutilisateur via SET ROLE, il perd les droits superutilisateur.

SET ROLE a des effets comparables à SET SESSION AUTHORIZATION mais la vérification des droits diffère. De plus, SET SESSION AUTHORIZATION détermine les rôles autorisés dans les commandes SET ROLE ultérieures alors que SET ROLE ne modifie pas les rôles accessibles par un futur SET ROLE.

SET ROLE ne traite pas les variables de session indiqué par les paramètres du rôle (et configurés avec ALTER ROLE ; cela ne survient qu'à la connexion.

SET ROLE ne peut pas être utilisé dans une fonction SECURITY DEFINER.

Exemples

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
  

Compatibilité

PostgreSQL autorise la syntaxe identifiant ("nom_role") alors que le SQL standard impose une chaîne littérale pour le nom du rôle. SQL n'autorise pas cette commande lors d'une transaction ; PostgreSQL n'est pas aussi restrictif, rien ne justifie cette interdiction. Les modificateurs SESSION et LOCAL sont des extensions PostgreSQL tout comme la syntaxe RESET.

Voir aussi