Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo del mascheramento dei dati dinamici con percorsi di tipo di dati SUPER
Amazon Redshift supporta l'associazione di politiche di mascheramento dei dati dinamici a percorsi di colonne di tipo SUPER. Per ulteriori informazioni sui tipi di dati SUPER, consultare [Dati semistrutturati in Amazon Redshift](super-overview.md).
Quando colleghi le politiche di mascheramento ai percorsi di colonne di tipo SUPER, tieni presenti le seguenti considerazioni.
+ Quando colleghi una politica di mascheramento al percorso di una colonna, tale colonna deve essere definita come tipo di dati SUPER. È possibile applicare le politiche di mascheramento solo a valori *scalari* del percorso SUPER. Non è possibile applicare le politiche di mascheramento a strutture o array complessi.
+ Puoi applicare diverse politiche di mascheramento a più valori scalari su una singola colonna SUPER, purché i percorsi SUPER non siano in conflitto. Ad esempio, i percorsi SUPER `a.b` e `a.b.c` sono in conflitto perché si trovano sullo stesso percorso, con `a.b` come padre di `a.b.c`. I percorsi SUPER `a.b.c` e `a.b.d` non sono in conflitto.
+ Amazon Redshift non può verificare che i percorsi associati a una politica di mascheramento esistano nei dati e siano del tipo previsto finché la politica non viene applicata al runtime della query dell'utente. Ad esempio, quando colleghi una politica di mascheramento che maschera i valori TEXT in un percorso SUPER contenente un valore INT, Amazon Redshift tenta di eseguire il casting del tipo di valore del percorso.
In tali situazioni, il comportamento di Amazon Redshift nel runtime dipende dalle impostazioni di configurazione per le query degli oggetti SUPER. Per impostazione predefinita, Amazon Redshift è in modalità permissiva e risolve i percorsi mancanti e i casting non validi come `NULL` per il percorso SUPER specificato. Per ulteriori informazioni sulle impostazioni di configurazione relative a SUPER, consulta [Configurazioni di SUPER](super-configurations.md).
+ SUPER è un tipo senza schema, il che significa che Amazon Redshift non può confermare l'esistenza del valore in un determinato percorso SUPER. Se colleghi una politica di mascheramento a un percorso SUPER che non esiste e Amazon Redshift è in modalità permissiva, Amazon Redshift risolve il percorso in un valore `NULL`. Ti consigliamo di considerare il formato previsto degli oggetti SUPER e la probabilità che abbiano attributi inaspettati quando colleghi le politiche di mascheramento ai percorsi delle colonne SUPER. Se ritieni che ci possa essere uno schema imprevisto nella colonna SUPER, prendi in considerazione la possibilità di collegare le politiche di mascheramento direttamente alla colonna SUPER. È possibile utilizzare le funzioni di informazioni di tipo SUPER per controllare attributi e tipi nonché usare `OBJECT_TRANSFORM` per mascherare i valori. Per ulteriori informazioni sulle funzioni di informazioni di tipo SUPER, consulta [Funzioni di informazioni sul tipo SUPER](c_Type_Info_Functions.md).
## Esempi
**Collegamento delle politiche di mascheramento ai percorsi SUPER**
L'esempio seguente collega più politiche di mascheramento a più percorsi di tipo SUPER in una colonna.
```
CREATE TABLE employees (
col_person SUPER
);
INSERT INTO employees
VALUES
(
json_parse('
{
"name": {
"first": "John",
"last": "Doe"
},
"age": 25,
"ssn": "111-22-3333",
"company": "Company Inc."
}
')
),
(
json_parse('
{
"name": {
"first": "Jane",
"last": "Appleseed"
},
"age": 34,
"ssn": "444-55-7777",
"company": "Organization Org."
}
')
)
;
GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC;
-- Create the masking policies.
-- This policy converts the given name to all uppercase letters.
CREATE MASKING POLICY mask_first_name
WITH(first_name TEXT)
USING ( UPPER(first_name) );
-- This policy replaces the given name with the fixed string 'XXXX'.
CREATE MASKING POLICY mask_last_name
WITH(last_name TEXT)
USING ( 'XXXX'::TEXT );
-- This policy rounds down the given age to the nearest 10.
CREATE MASKING POLICY mask_age
WITH(age INT)
USING ( (FLOOR(age::FLOAT / 10) * 10)::INT );
-- This policy converts the first five digits of the given SSN to 'XXX-XX'.
CREATE MASKING POLICY mask_ssn
WITH(ssn TEXT)
USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) );
-- Attach the masking policies to the employees table.
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.name.first)
TO PUBLIC;
ATTACH MASKING POLICY mask_last_name
ON employees(col_person.name.last)
TO PUBLIC;
ATTACH MASKING POLICY mask_age
ON employees(col_person.age)
TO PUBLIC;
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.ssn)
TO PUBLIC;
-- Verify that your masking policies are attached.
SELECT
policy_name,
TABLE_NAME,
priority,
input_columns,
output_columns
FROM
svv_attached_masking_policy;
policy_name | table_name | priority | input_columns | output_columns
-----------------+------------+----------+-----------------------------------+-----------------------------------
mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""]
mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""]
mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""]
mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""]
(4 rows)
-- Observe the masking policies taking effect.
SELECT col_person FROM employees ORDER BY col_person.age;
-- This result is formatted for ease of reading.
col_person
--------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc."
}
{
"name": {
"first": "JANE",
"last": "XXXX"
},
"age": 30,
"ssn": "XXX-XX-7777",
"company": "Organization Org."
}
```
Di seguito sono riportati alcuni esempi di collegamento di politiche di mascheramento non valide ai percorsi SUPER.
```
-- This attachment fails because there is already a policy
-- with equal priority attached to employees.name.last, which is
-- on the same SUPER path as employees.name.
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.name)
TO PUBLIC;
ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority
-- Create a masking policy that masks DATETIME objects.
CREATE MASKING POLICY mask_date
WITH(INPUT DATETIME)
USING ( INPUT );
-- This attachment fails because SUPER type columns can't contain DATETIME objects.
ATTACH MASKING POLICY mask_date
ON employees(col_person.company)
TO PUBLIC;
ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super
```
Di seguito è riportato un esempio di collegamento di una politica di mascheramento a un percorso SUPER che non esiste. Per impostazione predefinita, Amazon Redshift risolve il percorso come `NULL`.
```
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.not_exists)
TO PUBLIC;
SELECT col_person FROM employees LIMIT 1;
-- This result is formatted for ease of reading.
col_person
-----------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc.",
"not_exists": null
}
```