SET ROLE — initialise l'identifiant utilisateur courant de la session en cours
SET [ SESSION | LOCAL ] ROLE nom_rôle
SET [ SESSION | LOCAL ] ROLE NONE
RESET ROLE
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.
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
.
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
PostgreSQL autorise la syntaxe identifiant
("
) 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
nom_role
"SESSION
et LOCAL
sont des extensions
PostgreSQL tout comme la syntaxe RESET
.