ALTER TAG

Modifies the properties for an existing tag, including renaming the tag and setting a masking policy on a tag.

Any changes made to the tag go into effect when the next SQL query that uses the tag runs.

See also:

Specify tag values , Tag DDL reference

Syntax

ALTER TAG [ IF EXISTS ] <name> RENAME TO <new_name>

ALTER TAG [ IF EXISTS ] <name> { ADD | DROP } ALLOWED_VALUES '<val_1>' [ , '<val_2>' [ , ... ] ]

ALTER TAG <name> UNSET ALLOWED_VALUES

ALTER TAG <name> SET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]
                                                          [ FORCE ]

ALTER TAG <name> UNSET MASKING POLICY <masking_policy_name> [ , MASKING POLICY <masking_policy_2_name> , ... ]

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

ALTER TAG [ IF EXISTS ] <name> UNSET COMMENT
Copy

Parameters

name

Identifier for the tag. Assign the tag string value on an object using either a CREATE <object> statement or an ALTER <object> statement.

The identifier value must start with an alphabetic character and cannot contain spaces or special characters unless the entire identifier string is enclosed in double quotes (e.g. “My object”). Identifiers enclosed in double quotes are also case-sensitive.

For more details, see Identifier requirements

RENAME TO new_name

Specifies the new identifier for the tag; must be unique for your schema. The new identifier cannot be used if the identifier is already in place for a different tag.

For more details, see Identifier requirements.

You can move the object to a different database and/or schema while optionally renaming the object. To do so, specify a qualified new_name value that includes the new database and/or schema name in the form db_name.schema_name.object_name or schema_name.object_name, respectively.

Note

  • The destination database and/or schema must already exist. In addition, an object with the same name cannot already exist in the new location; otherwise, the statement returns an error.

  • Moving an object to a managed access schema is prohibited unless the object owner (that is, the role that has the OWNERSHIP privilege on the object) also owns the target schema.

ALLOWED_VALUES 'val_1' [ , 'val_2' [ , ... ] ]

Specifies a comma-separated list of the possible string values that can be assigned to the tag when the tag is set on an object using the corresponding CREATE <object> or ALTER <object> command.

The maximum number of tag values in this list is 300.

Default: NULL (all string values are allowed, including an empty string value (i.e. ' ')).

masking_policy_name [ , MASKING POLICY masking_policy_2_name , ... ]

Specifies a comma-separated list of masking policies that can assigned to the tag.

FORCE

Replaces a masking policy that is currently set on a tag with a different masking policy in a single statement.

Note that using the FORCE keyword replaces the masking policy when a policy of the same data type is already set on the tag.

If a masking policy is not currently set on the tag, specifying this keyword has no effect.

For details, see Replace a masking policy on a tag.

COMMENT = 'string_literal'

Specifies a comment for the tag.

Default: No value

UNSET

Specifies one (or more) properties and/or parameters to unset for the tag, which resets them to the defaults:

  • COMMENT

  • ALLOWED_VALUES

Access control requirements

A role used to execute this SQL command must have the following privileges at a minimum:

Privilege

Object

Notes

OWNERSHIP

Tag

This privilege is required to modify tag properties (e.g. comment, allowed values).

OWNERSHIP is a special privilege on an object that is automatically granted to the role that created the object, but can also be transferred using the GRANT OWNERSHIP command to a different role by the owning role (or any role with the MANAGE GRANTS privilege).

APPLY MASKING POLICY

Account

Assigning and replacing a masking policy on a tag requires the global APPLY MASKING POLICY privilege.

The USAGE privilege on the parent database and schema are required to perform operations on any object in a schema.

For instructions on creating a custom role with a specified set of privileges, see Creating custom roles.

For general information about roles and privilege grants for performing SQL actions on securable objects, see Overview of Access Control.

For additional details on tag DDL and privileges, see Managing tags.

Usage notes

  • For more information on tag DDL authorization, see required privileges.

  • Regarding assigning one or more masking policies to a tag:

    • A tag can have only one masking policy per data type.

      For example, a tag can have one policy for the STRING data type, one policy for the NUMBER data type, and so on.

    • If a masking policy already protects a column and the tag with a masking policy is set on the same column, the masking policy directly assigned to the column takes precedence over the masking policy assigned to the tag.

    • A tag cannot be dropped if a masking policy is assigned to the tag, nor can the masking policy be dropped if the masking policy is assigned to a tag.

  • Regarding replication, particularly with tag-based masking policies, see policy replication considerations.

  • Regarding metadata:

    Attention

    Customers should ensure that no personal data (other than for a User object), sensitive data, export-controlled data, or other regulated data is entered as metadata when using the Snowflake service. For more information, see Metadata fields in Snowflake.

Examples

Rename the cost_center tag to cost_center_na, where na specifies North America.

ALTER TAG cost_center RENAME TO cost_center_na;
Copy
Language: English