

 Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Exemples
<a name="r_GRANT-examples"></a>

 L’exemple suivant accorde le privilège SELECT sur la table SALES à l’utilisateur `fred`. 

```
grant select on table sales to fred;
```

L’exemple suivant accorde le privilège SELECT sur toutes les tables du schéma QA\$1TICKIT à l’utilisateur `fred`. 

```
grant select on all tables in schema qa_tickit to fred;
```

L’exemple suivant accorde tous les privilèges de schéma sur le schéma QA\$1TICKIT au groupe d’utilisateurs QA\$1USERS. Les privilèges de schéma sont CREATE et USAGE. USAGE accorde aux utilisateurs l’accès aux objets du schéma, mais n’accorde pas les privilèges tels que INSERT or SELECT sur ces objets. Accordez des privilèges sur chaque objet séparément.

```
create group qa_users;
grant all on schema qa_tickit to group qa_users;
```

L’exemple suivant accorde tous les privilèges sur la table SALES du schéma QA\$1TICKIT à tous les utilisateurs du groupe QA\$1USERS.

```
grant all on table qa_tickit.sales to group qa_users;
```

L’exemple suivant accorde tous les privilèges sur la table SALES du schéma QA\$1TICKIT à tous les utilisateurs des groupes QA\$1USERS et RO\$1USERS.

```
grant all on table qa_tickit.sales to group qa_users, group ro_users;
```

L’exemple suivant accorde le privilège DROP sur la table SALES du schéma QA\$1TICKIT à tous les utilisateurs du groupe QA\$1USERS.

```
grant drop on table qa_tickit.sales to group qa_users;>
```

La séquence de commandes suivante montre comment l’accès à un schéma n’accorde pas de privilèges sur une table du schéma. 

```
create user schema_user in group qa_users password 'Abcd1234';
create schema qa_tickit;
create table qa_tickit.test (col1 int);
grant all on schema qa_tickit to schema_user;

set session authorization schema_user;
select current_user;


current_user
--------------
schema_user
(1 row)


select count(*) from qa_tickit.test;


ERROR: permission denied for relation test [SQL State=42501]


set session authorization dw_user;
grant select on table qa_tickit.test to schema_user;
set session authorization schema_user;
select count(*) from qa_tickit.test;


count
-------
0
(1 row)
```

La séquence de commandes suivante montre comment l’accès à une vue n’implique pas l’accès à ses tables sous-jacentes. L’utilisateur appelé VIEW\$1USER ne peut pas sélectionner à partir de la table DATE, même si cet utilisateur s’est vu accorder tous les privilèges sur VIEW\$1DATE. 

```
create user view_user password 'Abcd1234';
create view view_date as select * from date;
grant all on view_date to view_user;
set session authorization view_user;
select current_user;


current_user
--------------
view_user
(1 row)


select count(*) from view_date;


count
-------
365
(1 row)


select count(*) from date;


ERROR:  permission denied for relation date
```

L’exemple suivant accorde le privilège SELECT sur les colonnes `cust_name` et `cust_phone` de la table `cust_profile` à l’utilisateur `user1`. 

```
grant select(cust_name, cust_phone) on cust_profile to user1;
```

L’exemple suivant accorde le privilège SELECT sur les colonnes `cust_name` et `cust_phone` et le privilège UPDATE sur la colonne `cust_contact_preference` de la table `cust_profile` au groupe `sales_group`. 

```
grant select(cust_name, cust_phone), update(cust_contact_preference) on cust_profile to group sales_group;
```

L’exemple suivant montre l’utilisation du mot-clé ALL pour accorder au groupe `sales_admin` les privilèges SELECT et UPDATE sur trois colonnes de la table `cust_profile`. 

```
grant ALL(cust_name, cust_phone,cust_contact_preference) on cust_profile to group sales_admin;
```

L’exemple suivant accorde à l’utilisateur `user2` le privilège SELECT sur la colonne `cust_name` de la vue `cust_profile_vw`. 

```
grant select(cust_name) on cust_profile_vw to user2;
```

## Exemples d’octroi d’accès à des unités de partage des données
<a name="r_GRANT-examples-datashare"></a>

Les exemples suivants illustrent les autorisations d’utilisation de partage de données GRANT sur une base de données spécifique ou un schéma créé à partir d’une unité de partage des données. 

Dans l’exemple suivant, un administrateur côté producteur accorde à l’espace de noms spécifié l’autorisation USAGE sur l’unité de partage des données `salesshare`. 

```
GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d';
```

Dans l’exemple suivant, un administrateur côté consommateur accorde à `Bob` l’autorisation USAGE sur la base de données `sales_db`.

```
GRANT USAGE ON DATABASE sales_db TO Bob;
```

Dans l’exemple suivant, un administrateur côté consommateur accorde au rôle `Analyst_role`l’autorisation GRANT USAGE sur le schéma `sales_schema`. `sales_schema` est un schéma externe qui pointe vers sales\$1db.

```
GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role;
```

À ce stade, `Bob` et `Analyst_role` peuvent accéder à tous les objets de base de données dans `sales_schema` et`sales_db`.

L’exemple suivant montre comment accorder une autorisation de niveau objet supplémentaire pour les objets d’une base de données partagée. Ces autorisations supplémentaires ne sont nécessaires que si la commande CREATE DATABASE utilisée pour créer la base de données partagée utilisait la clause WITH PERMISSIONS. Si la commande CREATE DATABASE n’a pas utilisé la clause WITH PERMISSIONS, accorder l’autorisation USAGE sur la base de données partagée donne un accès complet à tous les objets de cette base de données.

```
GRANT SELECT ON sales_db.sales_schema.tickit_sales_redshift to Bob;
```

## Exemples d’octroi d’autorisations étendues
<a name="r_GRANT-examples-scoped"></a>

L’exemple suivant autorise le rôle `Sales` à utiliser tous les schémas actuels et futurs de la base de données `Sales_db`.

```
GRANT USAGE FOR SCHEMAS IN DATABASE Sales_db TO ROLE Sales;
```

L’exemple suivant accorde à l’utilisateur `alice` l’autorisation SELECT pour toutes les tables actuelles et futures de la base de données `Sales_db`, et donne aussi à `alice` l’autorisation d’accorder à d’autres utilisateurs des autorisations étendues sur les tables de `Sales_db`.

```
GRANT SELECT FOR TABLES IN DATABASE Sales_db TO alice WITH GRANT OPTION;
```

L’exemple suivant accorde à l’utilisateur `bob` l’autorisation EXECUTE pour les fonctions du schéma `Sales_schema`.

```
GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob;
```

L’exemple suivant accorde au `Sales` rôle toutes les autorisations pour toutes les tables du schéma `ShareSchema` de la base de données `ShareDb`. Lorsque vous spécifiez le schéma, vous pouvez spécifier la base de données du schéma en utilisant le format en deux parties `database.schema`.

```
GRANT ALL FOR TABLES IN SCHEMA ShareDb.ShareSchema TO ROLE Sales;
```

L’exemple suivant est le même que le précédent. Vous pouvez spécifier la base de données à l’aide du mot-clé `DATABASE` au lieu d’utiliser un format en deux parties.

```
GRANT ALL FOR TABLES IN SCHEMA ShareSchema DATABASE ShareDb TO ROLE Sales;
```

## Exemples d’octroi du privilège ASSUMEROLE
<a name="r_GRANT-examples-assumerole"></a>

Voici des exemples d’octroi du privilège ASSUMEROLE.

L’exemple suivant montre l’instruction REVOKE qu’un super-utilisateur exécute une fois sur le cluster pour activer l’utilisation du privilège ASSUMEROLE pour les utilisateurs et les groupes. Ensuite, le super-utilisateur accorde le privilège ASSUMEROLE aux utilisateurs et aux groupes pour les commandes appropriées. Pour obtenir des informations sur l’activation du privilège ASSUMEROLE pour les utilisateurs et les groupes, consultez [Notes d’utilisation pour l’octroi de l’autorisation ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole).

```
revoke assumerole on all from public for all;
```

L’exemple suivant accorde le privilège ASSUMEROLE à l’utilisateur `reg_user1` pour le rôle IAM `Redshift-S3-Read` pour effectuer des opérations COPY. 

```
grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-S3-Read'
to reg_user1 for copy;
```

L’exemple suivant accorde le privilège ASSUMEROLE à l’utilisateur `reg_user1` pour la chaîne de rôles IAM `RoleA`, `RoleB` pour effectuer des opérations UNLOAD. 

```
grant assumerole
on 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB'
to reg_user1
for unload;
```

Voici un exemple de commande UNLOAD utilisant la chaîne de rôles IAM `RoleA`, `RoleB`.

```
unload ('select * from venue limit 10')
to 's3://companyb/redshift/venue_pipe_'
iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';
```

L’exemple suivant accorde le privilège ASMEROLE à l’utilisateur `reg_user1` pour le rôle IAM `Redshift-Exfunc` pour créer des fonctions externes. 

```
grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-Exfunc'
to reg_user1 for external function;
```

L’exemple suivant accorde le privilège ASSUMEROLE à l’utilisateur `reg_user1` pour le rôle IAM `Redshift-model` pour créer des modèles de machine learning. 

```
grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-ML'
to reg_user1 for create model;
```

## Exemples d’octroi de privilèges ROLE
<a name="r_GRANT-examples-role"></a>

L’exemple suivant accorde le rôle sample\$1role1 à l’utilisateur user1.

```
CREATE ROLE sample_role1;
GRANT ROLE sample_role1 TO user1;
```

L’exemple suivant accorde le rôle sample\$1role1 à l’utilisation user1 avec la clause WITH ADMIN OPTION, définit la séance actuelle pour user1, et user1 accorde le rôle sample\$1role1 à l’utilisateur user2.

```
GRANT ROLE sample_role1 TO user1 WITH ADMIN OPTION;
SET SESSION AUTHORIZATION user1;
GRANT ROLE sample_role1 TO user2;
```

L’exemple suivant accorde le rôle sample\$1role1 au rôle sample\$1role2.

```
GRANT ROLE sample_role1 TO ROLE sample_role2;
```

L’exemple suivant accorde le rôle sample\$1role2 au rôle sample\$1role3 et au rôle sample\$1role4. Ensuite, il tente d’accorder le rôle sample\$1role3 au rôle sample\$1role1.

```
GRANT ROLE sample_role2 TO ROLE sample_role3;
GRANT ROLE sample_role3 TO ROLE sample_role2;
ERROR: cannot grant this role, a circular dependency was detected between these roles
```

L’exemple suivant accorde les privilèges système CREATE USER au rôle sample\$1role1.

```
GRANT CREATE USER TO ROLE sample_role1;
```

L’exemple suivant accorde le rôle défini par le système `sys:dba` à l’utilisateur user1.

```
GRANT ROLE sys:dba TO user1;
```

L’exemple suivant tente d’accorder le rôle sample\$1role3 dans une dépendance circulaire au rôle sample\$1role2.

```
CREATE ROLE sample_role3;
GRANT ROLE sample_role2 TO ROLE sample_role3;
GRANT ROLE sample_role3 TO ROLE sample_role2; -- fail
ERROR:  cannot grant this role, a circular dependency was detected between these roles
```