ALTER JOIN POLICY¶

Syntaxe¶

ALTER JOIN POLICY [ IF EXISTS ] <name> RENAME TO <new_name>

ALTER JOIN POLICY [ IF EXISTS ] <name> SET BODY -> <expression>

ALTER JOIN POLICY <name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ]

ALTER JOIN POLICY <name> UNSET TAG <tag_name> [ , <tag_name> ... ]

ALTER JOIN POLICY [ IF EXISTS ] <name> SET COMMENT = '<string_literal>'

ALTER JOIN POLICY [ IF EXISTS ] <name> UNSET COMMENT

Paramètres¶

name

Spécifie l’identificateur de la politique de jointure à modifier.

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.

RENAME TO new_name

Spécifie le nouvel identificateur de la politique de jointure ; il doit être unique pour votre schéma. Le nouvel identificateur ne peut pas être utilisé si l’identificateur est déjà en place pour une politique de jointure différente.

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

Vous pouvez déplacer l’objet vers une autre base de données et/ou un autre schéma tout en renommant éventuellement l’objet. Pour ce faire, spécifiez une valeur new_name qualifiée qui inclut le nouveau nom de la base de données et/ou du schéma sous la forme db_name.schema_name.object_name ou schema_name.object_name, respectivement.

Note

• La base de données et/ou le schéma de destination doivent déjà exister. En outre, un objet portant le même nom ne peut pas déjà exister dans le nouvel emplacement ; sinon, l’instruction renvoie une erreur.

• Le déplacement d’un objet vers un schéma d’accès géré est interdit sauf si le propriétaire de l’objet (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’objet) est également propriétaire du schéma cible.

SET ...

Spécifie une (ou plusieurs) propriété(s) à définir pour la politique de jointure :

BODY -> expression

Expression SQL qui détermine les restrictions d’une politique de jointure.

Pour définir le corps de la politique de jointure, appelez la fonction JOIN_CONSTRAINT, qui renvoie TRUE ou FALSE. Lorsque la fonction renvoie TRUE, les requêtes doivent utiliser une jointure pour renvoyer les résultats.

La syntaxe de la fonction JOIN_CONSTRAINT est la suivante :

JOIN_CONSTRAINT (
  { JOIN_REQUIRED => <boolean_expression> }
  )

Copy

Où :

JOIN_REQUIRED => boolean_expression

Indique si une jointure est exigée dans les requêtes lorsque les données sont sélectionnées dans des tables ou des vues auxquelles la politique de jointure a été attribuée.

Le corps d’une politique ne peut pas faire référence à des fonctions, des tables ou des vues définies par l’utilisateur.

Les colonnes de jointure autorisées sont spécifiées dans l’instruction CREATE ou ALTER pour la table ou la vue à laquelle la politique est appliquée, et non dans l’instruction CREATE JOIN POLICY.

TAG tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ]

Spécifie le nom de la balise et la valeur de la chaîne de la balise.

La valeur de la balise est toujours une chaîne de caractères et le nombre maximum de caractères pour la valeur de la balise est 256.

Pour plus d’informations sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.

COMMENT = 'string_literal'

Ajoute un commentaire ou remplace le commentaire existant pour la politique de jointure.

Par défaut : aucune valeur

UNSET ...

Spécifie une ou plusieurs propriétés et/ou paramètres à désactiver, en les réinitialisant à leurs valeurs par défaut, pour la politique de jointure :

• TAG tag_name [ , tag_name ... ]

• COMMENT

Lors de la réinitialisation d’une propriété ou d’un paramètre, spécifiez seulement le nom ; si vous spécifiez une valeur pour la propriété, vous obtiendrez une erreur.

Exigences en matière de contrôle d’accès¶

Un rôle utilisé pour exécuter cette opération doit au minimum disposer des privilèges suivants :

Le privilège USAGE relatif à la base de données et au schéma parents est exigé pour effectuer des opérations sur tout objet d’un schéma.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Pour plus d’informations sur la DDL de politique de jointure et les privilèges, voir Privilèges et commandes.

Notes sur l’utilisation¶

• Si vous souhaitez mettre à jour une politique de jointure existante et que vous avez besoin de voir le corps actuel de la politique, exécutez la commande DESCRIBE JOIN POLICY. Vous pouvez également utiliser la fonction GET_DDL pour obtenir la définition complète de la politique de jointure, y compris son corps.

• Le déplacement d’une politique de jointure vers un schéma d’accès géré (utilisant la syntaxe ALTER JOIN POLICY … RENAME TO) est interdit sauf si le propriétaire de la politique de jointure (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur la politique de jointure) est également propriétaire du schéma cible.

• Concernant les métadonnées :

  Attention

  Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

Exemples¶

Modifier l’expression SQL pour une politique de jointure :

ALTER JOIN POLICY jp3 SET BODY -> JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE);

Renommer une politique de jointure :

ALTER JOIN POLICY my_join_policy RENAME TO my_join_policy_2;