GRANT — Définir les droits d'accès
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { [ TABLE ] nom_table [, ...]
         | ALL TABLES IN SCHEMA nom_schéma [, ...] }
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( nom_colonne [, ...] )
    [, ...] | ALL [ PRIVILEGES ] ( nom_colonne [, ...] ) }
    ON [ TABLE ] nom_table [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { { USAGE | SELECT | UPDATE }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { SEQUENCE nom_séquence [, ...]
         | ALL SEQUENCES IN SCHEMA nom_schéma [, ...] }
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] | ALL [ PRIVILEGES ] }
    ON DATABASE nom_base [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON DOMAIN nom_domaine [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN DATA WRAPPER nom_fdw [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON FOREIGN SERVER nom_serveur [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
    ON { { FUNCTION | PROCEDURE | ROUTINE } nom_routine [ ( [ [ mode_arg ] [ nom_arg ] type_arg [, ...] ] ) ] [, ...]
         | ALL { FUNCTIONS | PROCEDURES | ROUTINES } IN SCHEMA nom_schéma [, ...] }
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON LANGUAGE nom_lang [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | UPDATE } [, ...] | ALL [ PRIVILEGES ] }
    ON LARGE OBJECT loid [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] }
    ON SCHEMA nom_schéma [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
    ON TABLESPACE tablespace_name [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
    ON TYPE nom_type [, ...]
    TO spécification_rôle [, ...] [ WITH GRANT OPTION ]
GRANT nom_role [, ...] TO spécification_rôle [, ...]
    [ WITH ADMIN OPTION ]
    [ GRANTED BY spécification_rôle ]
où spécification_rôle peut valoir :
    [ GROUP ] nom_rôle
  | PUBLIC
  | CURRENT_USER
  | SESSION_USER
   La commande GRANT a deux variantes basiques : la première
   donne des droits sur un objet de la base de données (table, colonne, vue,
   table distante, séquence, base de données, wrapper de données distantes, serveur distant,
   fonction, procédure, langage de procédure, schéma ou espace
   logique), la seconde gère les appartenances à un rôle. Ces variantes sont
   assez similaires mais somme toute assez différentes pour être
   décrites séparément.
  
    Cette variante de la commande GRANT donne des droits
    spécifiques sur un objet de la base de données a un ou plusieurs rôles.
    Ces droits sont ajoutés à ceux déjà possédés, s'il y en a.
   
    Le mot clé PUBLIC indique que les droits sont donnés à
    tous les rôles, y compris ceux créés ultérieurement.
    PUBLIC peut être vu comme un groupe implicitement
    défini qui inclut en permanence tous les rôles. Un rôle
    particulier dispose de la somme des droits qui lui sont acquis en propre, des droits
    de tout rôle dont il est membre et des droits donnés à PUBLIC.
   
    Si WITH GRANT OPTION est précisé, celui qui reçoit le
    droit peut le transmettre à son tour (NDT : par la suite on parlera
    d'«  option de transmission de droit  », là où en
    anglais il est fait mention de «  grant options  »).
    Sans l'option GRANT, l'utilisateur ne peut pas le faire. Cette option ne
    peut pas être donnée à PUBLIC.
   
Il n'est pas nécessaire d'accorder des droits au propriétaire d'un objet (habituellement l'utilisateur qui l'a créé) car, par défaut, le propriétaire possède tous les droits. (Le propriétaire peut toutefois choisir de révoquer certains de ses propres droits.)
Le droit de supprimer un objet ou de modifier sa définition n'est pas configurable avec cette commande. Il est spécifique au propriétaire de l'objet. Ce droit ne peut ni être donné ni supprimé. Néanmoins, il est possible d'avoir le même effet en rendant un utilisateur membre du rôle qui possède cet object ou en le supprimant de ce rôle. Le propriétaire a aussi implicitement les options de transmission de droits pour l'objet.
Les droits possibles sont :
SELECTINSERTUPDATEDELETETRUNCATEREFERENCESTRIGGERCREATECONNECTTEMPORARYEXECUTEUSAGETypes spécifiques de droits, comme définis dans Section 5.7.
TEMP
       Autre écriture de TEMPORARY.
      
ALL PRIVILEGES
       Donner tous les droits disponibles pour ce type d'objet. Le mot-clé
       PRIVILEGES est optionnel dans
       PostgreSQL, bien qu'il soit requis en SQL.
      
   La syntaxe FUNCTION fonctionne pour les fonctions
   simples, les fonctions d'agrégat, et les fonctions de fenêtrage, mais pas
   pour les procédures ; utilisez PROCEDURE pour ces
   dernières. Vous pouvez aussi utiliser ROUTINE pour faire
   référence à une fonction simple, une fonction d'agrégat, une fonction de
   fenêtrage ou une procédure.
  
   Il existe aussi une option pour donner les droits sur tous les objets de
   même type dans un ou plusieurs schémas. Cette fonctionnalité est
   actuellement supportée par les tables, séquences, fonctions et procédures.
   ALL TABLES affecte aussi les vues et les tables
   externes, tout comme la commande GRANT de cet objet.
   ALL FUNCTIONS affecte aussi les fonctions d'agrégat et
   les fonctions de fenêtrage, mais pas les procédures, encore une fois tout
   comme la commande GRANT spécifique à l'objet. Utilisez
   ALL ROUTINES pour inclure les procédures.
   
    Cette variante de la commande GRANT définit l'appartenance
    d'un (ou plusieurs) rôle(s) à un autre. L'appartenance à un rôle est importante
    car elle offre tous les droits accordés à un rôle à l'ensemble de ses membres.
   
    Si WITH ADMIN OPTION est spécifié, le membre peut à la
    fois en octroyer l'appartenance à d'autres rôles, et la révoquer. Sans cette
    option, les utilisateurs ordinaires ne peuvent pas le faire. Un rôle ne
    dispose pas de l'option WITH ADMIN OPTION lui-même mais il
    peut donner ou enlever son appartenance à partir d'une session où l'utilisateur
    correspond au rôle. Les superutilisateurs peuvent donner ou supprimer
    l'appartenance à tout rôle. Les rôles disposant de l'attribut
    CREATEROLE peuvent donner ou supprimer l'appartenance à
    tout rôle qui n'est pas un superutilisateur.
   
    Si GRANTED BY est utilisé, l'ajout du droit est enregistré
    comme étant fait avec le rôle indiqué. Seuls les superutilisateurs peuvent
    utiliser cette option, sauf quand le nom indiqué est le même que celui qui
    exécute la commande.
   
    Contrairement au cas avec les droits, l'appartenance à un rôle ne peut pas
    être donné à PUBLIC. Notez aussi que ce format de la
    commande n'autorise pas le mot GROUP dans spécification_rôle.
   
La commande REVOKE est utilisée pour retirer les droits d'accès.
   Depuis PostgreSQL 8.1, le concept des
   utilisateurs et des groupes a été unifié en un seul type d'entité appelé
   rôle. Il n'est donc plus nécessaire d'utiliser le mot clé
   GROUP pour indiquer si le bénéficiaire est un
   utilisateur ou un groupe. GROUP est toujours autorisé
   dans cette commande mais est ignoré.
  
   Un utilisateur peut exécuter des SELECT,
   INSERT, etc. sur une colonne si il a le privilège soit sur
   cette colonne spécifique, soit sur la table entière. Donner un privilège de
   table puis le révoquer pour une colonne ne fera pas ce que vous pourriez
   espérer : l'autorisation au niveau de la table n'est pas affectée par
   une opération au niveau de la colonne.
  
   Quand un utilisateur, non propriétaire d'un objet, essaie d'octroyer des
   droits sur cet objet, la commande échoue si l'utilisateur
   n'a aucun droit sur l'objet. Tant que des privilèges existent, la commande
   s'exécute, mais n'octroie que les droits pour lesquels l'utilisateur dispose
   de l'option de transmission.
   Les formes GRANT ALL PRIVILEGES engendrent un message d'avertissement
   si aucune option de transmission de droit n'est détenue, tandis que les autres formes
   n'engendrent un message que lorsque les options de transmission du privilège concerné
   par la commande ne sont pas détenues. (Cela s'applique aussi au
   propriétaire de l'objet, mais comme on considère toujours que ce dernier détient
   toutes les options de transmission, le problème ne se pose jamais.)
  
   Les superutilisateurs de la base de données
   peuvent accéder à tous les objets sans tenir compte des droits qui les régissent.
   Cela est comparable aux droits de root sur un système
   Unix. Comme avec root, il est déconseillé d'opérer en tant que
   superutilisateur, sauf en cas d'impérieuse nécessité.
  
   Si un superutilisateur lance une commande GRANT ou
   REVOKE, tout se passe comme si la commande était exécutée
   par le propriétaire de l'objet concerné. Les droits octroyés par
   cette commande semblent ainsi l'avoir été par le propriétaire de l'objet.
   (L'appartenance à rôle, elle, semble être donnée par le rôle conteneur.)
  
   GRANT et REVOKE peuvent aussi être
   exécutées par un rôle qui n'est pas le propriétaire de l'objet considéré,
   mais est membre du rôle propriétaire de l'objet, ou membre du rôle
   titulaire du privilège WITH GRANT OPTION sur cet objet.
   Dans ce cas, les droits sont enregistrés comme donnés par le rôle
   propriétaire de l'objet ou titulaire du privilège WITH GRANT
    OPTION. Par exemple, si la table t1 appartient
   au rôle g1, dont le rôle u1 est
   membre, alors u1 peut donner les droits sur
   t1 à u2, mais ces droits apparaissent
   octroyés directement par g1. Tout autre membre du rôle
   g1 peut les révoquer par la suite.
  
   Si le rôle qui exécute GRANT détient, de manière indirecte,
   les droits souhaités à travers plus d'un niveau d'appartenance, il est difficile
   de prévoir le rôle reconnu comme fournisseur du privilège. Dans de tels cas,
   le meilleur moyen d'utiliser SET ROLE est de devenir le rôle
   qui doit octroyer les droits.
  
   Donner un droit sur une table n'étend pas automatiquement les droits
   sur les séquences utilisées par cette table, ceci incluant les
   séquences liées par des colonnes de type SERIAL. Les droits
   sur les séquences doivent être donnés séparément.
  
Voir Section 5.7 pour plus d'informations sur les types de droit spécifiques, ainsi que sur la façon d'inspecter les droits sur les objets.
   Donner le droit d'insertion à tous les utilisateurs sur la table
   films :
   
GRANT INSERT ON films TO PUBLIC;
  Donner tous les droits possibles à l'utilisateur manuel sur la vue
  genres :
  
GRANT ALL PRIVILEGES ON genres TO manuel;
  Bien que la commande ci-dessus donne tous les droits lorsqu'elle
  est exécutée par un superutilisateur ou par le propriétaire de
  genres, exécutée par quelqu'un d'autre, elle
  n'accorde que les droits pour lesquels cet utilisateur possède l'option de transmission.
 
  Rendre joe membre de admins :
  
GRANT admins TO joe;
  Conformément au standard SQL, le mot clé PRIVILEGES
  est requis dans ALL PRIVILEGES. Le standard SQL
  n'autorise pas l'initialisation des droits sur plus d'un objet par commande.
 
  PostgreSQL autorise un propriétaire d'objet
  à révoquer ses propres droits ordinaires : par exemple, le
  propriétaire d'un objet peut le placer en lecture seule pour lui-même en
  révoquant ses propres droits INSERT,
  UPDATE, DELETE et
  TRUNCATE. Le standard SQL
  ne l'autorise pas. La raison en est que
  PostgreSQL traite les droits du propriétaire
  comme ayant été donnés par le propriétaire ; il peut, de ce fait, aussi les
  révoquer. Dans le standard SQL, les droits du propriétaire sont donnés par
  une entité « _SYSTEM ». N'étant pas « _SYSTEM », le propriétaire
  ne peut pas révoquer ces droits.
 
  D'après le standard SQL, les options de cette commande peuvent être données
  à PUBLIC ; PostgreSQL supporte seulement l'ajout des
  options de droits aux rôles.
 
  Le standard SQL autorise l'utilisation de l'option GRANTED
   BY pour toutes les formes de GRANT. PostgreSQL
  l'accepte uniquement pour rendre un rôle membre d'un autre rôle, et même
  là, seuls les superutilisateurs peuvent l'utiliser.
 
  Le standard SQL fournit un droit USAGE sur d'autres
  types d'objet : jeux de caractères, collations, conversions.
 
  Dans le standard SQL, seules les séquences ont un droit USAGE
  qui contrôle l'utilisation de l'expression NEXT VALUE FOR,
  un équivalent de la fonction nextval dans PostgreSQL.
  Les droits SELECT et UPDATE des
  séquences sont une extension de PostgreSQL. L'application du droit
  USAGE de la séquence à la fonction
  currval est aussi une extension PostgreSQL (comme l'est
  la fonction elle-même).
 
Les droits sur les bases de données, tablespaces, langages, schémas et séquences sont des extensions PostgreSQL.