USE SECONDARY ROLES¶

Spécifie les rôles secondaires actifs/actuels de la session. Les rôles secondaires actuellement actifs définissent le contexte qui détermine si l’utilisateur actuel dispose des privilèges nécessaires pour effectuer les actions SQL.

Notez que l’autorisation d’exécuter des instructions CREATE <objet> pour créer des objets est fournie par le rôle primaire.

Pour plus d’informations, voir application du rôle secondaire.

Voir aussi :: USE ROLE

Syntaxe¶

USE SECONDARY ROLES {
      ALL
    | NONE
    | <role_name> [ , <role_name> ... ]
  }

Paramètres¶

ALL

Tous les rôles qui ont été accordés à l’utilisateur en plus du rôle primaire actif actuel.

Notez que l’ensemble des rôles est réévalué lors de l’exécution de chaque instruction SQL. Si des rôles supplémentaires sont accordés à l’utilisateur, et que celui-ci exécute une nouvelle instruction SQL, les rôles nouvellement accordés sont des rôles secondaires actifs pour la nouvelle instruction SQL. La même logique s’applique aux rôles qui sont révoqués à un utilisateur.

NONE

Désactive les rôles secondaires. L’autorisation pour toutes les actions SQL est fournie par le rôle primaire.

role_name [ , role_name ... ]

Active les rôles spécifiés comme rôles secondaires. Les rôles secondaires peuvent être des rôles de compte définis par l’utilisateur ou des rôles système. Spécifiez le nom du rôle tel qu’il est stocké dans Snowflake.

Si l’identificateur contient des espaces ou des caractères spéciaux, toute la chaîne doit être délimitée par des guillemets doubles. Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus d’informations, voir Exigences relatives à l’identificateur.

Notes sur l’utilisation¶

Lorsque vous spécifiez des noms de rôles individuels :
- Chaque rôle nommé doit avoir été accordé à l’utilisateur actuel. La commande valide immédiatement chaque rôle spécifié ; si un rôle n’a pas été accordé, la commande échoue avec une erreur.
- La commande enregistre l’ensemble souhaité de rôles secondaires pour la session. Les rôles activés pour chaque instruction SQL suivante peut être un sous-ensemble de l’ensemble souhaité, par exemple, si une politique de session restreint certains rôles secondaires.
Lorsque ALL est spécifié, la commande ne valide pas les attributions de rôle à l’avance. Au lieu de cela, les rôles secondaires actifs sont déterminés dynamiquement lorsque chaque instruction SQL s’exécute. Cela signifie que les rôles nouvellement accordés sont activés automatiquement et que les rôles révoqués ne sont plus actifs sans qu’il soit nécessaire de réémettre la commande.
Si une politique de session restreint les rôles secondaires qui peuvent être activés, la commande réussit toujours mais peut renvoyer un message d’information indiquant que les rôles secondaires activés seront limités par la politique.

Exemples¶

USE SECONDARY ROLES ALL;

USE SECONDARY ROLES test_role_1, test_role_2;