IS_DATABASE_ROLE_IN_SESSION¶

Syntaxe¶

Littéral — spécifier un rôle de base de données directement :

IS_DATABASE_ROLE_IN_SESSION( '<string_literal>' )

Non-littéral — spécifier une colonne :

IS_DATABASE_ROLE_IN_SESSION( <column_name> )

Copy

Arguments¶

'string_literal'

Nom du rôle de la base de données.

Indiquez le nom relatif du rôle de la base de données. La fonction est évaluée à False si vous spécifiez le nom complet.

column_name

Le nom de la colonne dans une table ou une vue.

Notes sur l’utilisation¶

Ces remarques ne s’appliquent qu’à la fonction IS_DATABASE_ROLE_IN_SESSION :

• Utilisez cette table pour prévoir l’évaluation de la fonction lorsque l’argument de la fonction est une chaîne littérale :

  Contexte	Évaluation
  Requête.	Base de données de la session.
  Définition de la table ou de la vue avec la clause WHERE.	Dépend des éléments suivants : Si une base de données est utilisée et que vous utilisez le nom relatif de la table ou de la vue, le contexte est la base de données utilisée (base de données de session). Si vous spécifiez le nom complet de la table ou de la vue, le contexte est la base de données qui contient la table ou la vue.
  Table ou vue protégée.	Base de données contenant la table ou la vue.
  Procédure stockée avec droits du propriétaire.	Base de données contenant la procédure stockée.
  Procédure stockée avec droits de l’appelant.	Base de données de la session.
  UDF	Base de données contenant la table ou la vue protégée. Si l’UDF n’est pas appelé dans une politique, la fonction évalue la base de données qui contient l’UDF.

• Un rôle de base de données devient actif dans la hiérarchie des rôles lorsque la base de données contenant le rôle de base de données est en cours d’utilisation ou lors de l’interrogation d’une table dans la même base de données que celle contenant le rôle de base de données.

  Si vous êtes un consommateur de partages de données et que vous utilisez un rôle de base de données pour interroger des données protégées par une politique, chargez la base de données contenant la table protégée avec une commande USE DATABASE database_name avant d’interroger les données protégées par une politique. Il est également possible de spécifier le nom complet de l’objet protégé dans la requête. L’une ou l’autre de ces approches active le rôle de base de données dans la hiérarchie des rôles du rôle actuel de l’utilisateur. Pour plus de détails, voir Partagez des données protégées par une politique.

• Lorsque vous spécifiez cette fonction dans le body d’une politique d’accès aux données, telle qu’une politique de masquage ou d’accès aux lignes, la fonction utilise la base de données et le schéma de la table protégée.

  Par exemple, si vous ajoutez une politique d’accès aux lignes à la table hr.tables.empl_info, la fonction recherche son argument, le nom du rôle de la base de données ou le nom de la colonne, dans la base de données hr car c’est cette dernière qui contient la table protégée.

• Vous devez éviter les structures de requête qui exigent que Snowflake crée une vue en ligne. Dans ce contexte, une vue en ligne est une vue temporaire que Snowflake crée pour déterminer le résultat de la requête. Par exemple, si votre requête appelle cette fonction et que vous spécifiez une clause WITH au début de la requête ou que vous spécifiez une sous-requête dans la clause FROM, Snowflake renvoie une erreur :

  Could not resolve the database for IS_DATABASE_ROLE_IN_SESSION({})
  

  Où {} est un caractère de remplacement pour l’argument de la fonction dans votre requête. La raison de l’erreur est que Snowflake ne dispose pas de suffisamment d’informations pour évaluer le contexte de l’argument de la fonction. Pour résoudre le message d’erreur, simplifiez votre requête, en supprimant par exemple la clause WITH ou la sous-requête dans la clause FROM.

• Lorsque la valeur DEFAULT_SECONDARY_ROLES de la propriété de l’utilisateur est ALL , la fonction renvoie True si tout rôle de compte accordé à l’utilisateur hérite des privilèges du rôle de base de données spécifié.

• Lorsque cette fonction est utilisée dans le cadre d’une politique de masquage ou d’une politique d’accès aux lignes qui protège les données partagées, il convient de s’assurer que la base de données contenant la politique et les données protégées par la politique sont toutes deux partagées avec le compte de consommateur. La politique et les données protégées par la politique peuvent se trouver dans la même base de données ou dans des bases de données différentes. Pour plus de détails, voir Partagez des données protégées par une politique.

Ces remarques s’appliquent aux fonctions IS_DATABASE_ROLE_IN_SESSION et IS_ROLE_IN_SESSION :

• Utilisez une seule syntaxe.

• Syntaxe littérale :

  • Un seul nom de rôle de base de données peut être transmis en tant qu’argument.

  • L’argument doit être une chaîne et utiliser la même casse que celle utilisée pour stocker le rôle dans Snowflake. Pour plus de détails, voir Exigences relatives à l’identificateur.

  • Le nom d’un rôle de compte n’est pas pris en charge.

• Syntaxe non littérale :

  • Une seule colonne peut être validée en tant qu’argument.

  • La colonne doit avoir un type de données STRING.

  • Spécifiez la colonne comme l’une des suivantes :

    • column_name

    • table_name.column_name

    • schema_name.table_name.column_name

    • database_name.schema_name.table_name.column_name

• Colonnes virtuelles :

  Une colonne virtuelle, qui contient le résultat d’une valeur calculée à partir d’une expression plutôt que la valeur calculée stockée dans la table, n’est pas prise en charge.

  SELECT IS_ROLE_IN_SESSION(UPPER(authz_role)) FROM t1;
  

  Copy

  Une colonne virtuelle n’est prise en charge que si l’expression comporte un alias pour le nom de la colonne :

  CREATE VIEW v2 AS
  SELECT
    authz_role,
    UPPER(authz_role) AS upper_authz_role
  FROM t2;
  
  SELECT IS_ROLE_IN_SESSION(upper_authz_role) FROM v2;
  

  Copy

• Politiques :

  Si vous utilisez ces fonctions avec une politique de masquage ou une politique d’accès aux lignes, vérifiez que votre compte Snowflake est bien en Enterprise Edition ou une version supérieure.

  Snowflake recommande d’utiliser cette fonction lorsque les conditions de la politique doivent évaluer la hiérarchie des rôles et les privilèges hérités.

• Cache du résultat :

  Si vous utilisez cette fonction dans une politique de masquage ou une politique d’accès aux lignes et que ni la politique ni la table ou la colonne protégée par la politique ne changent par rapport à une requête précédente, vous pouvez utiliser la fonction RESULT_SCAN pour renvoyer les résultats d’une requête sur la table protégée. Le cache de résultat s’applique uniquement lors de l’utilisation de la syntaxe non littérale.

• Ces fonctions ne peuvent pas être utilisée dans la définition de la vue matérialisée, car les fonctions ne sont pas déterministes et Snowflake ne peut pas déterminer les données à matérialiser.

Exemples¶

Vérifiez si les privilèges accordés à un rôle spécifique sont hérités par le rôle actuel dans la session :

SELECT IS_DATABASE_ROLE_IN_SESSION('R1');

+-----------------------------------+
| IS_DATABASE_ROLE_IN_SESSION('R1') |
+-----------------------------------+
| True                              |
+-----------------------------------+

Renvoie les valeurs des rôles de base de données pour la colonne nommée ROLE_NAME :

SELECT *
FROM myb.s1.t1
WHERE IS_DATABASE_ROLE_IN_SESSION(role_name);

Copy

Pour d’autres exemples liés au partage sécurisé de données, consultez Partagez des données protégées par une politique.