Quand un objet est créé, il se voit affecter un propriétaire. Le propriétaire est normalement le rôle qui a exécuté la requête de création. Pour la plupart des objets, l'état initial est que seul le propriétaire et les superutilisateurs peuvent faire quelque chose avec cet objet. Pour permettre aux autres rôles de l'utiliser, des droits doivent être donnés.

Il existe un certain nombre de droits différents : SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE, SET, ALTER SYSTEM et MAINTAIN. Les droits applicables à un objet particulier varient selon le type d'objet (table, fonction...). Plus de détails sur la signification de ces droits sont donnés ci-dessous. La section et les chapitres suivants présentent l'utilisation de ces droits.

Le droit de modifier ou détruire un objet est inhérent au propriétaire de l'objet et ne peut ni être donné ni être enlevé. Néanmoins, comme tous les droits, il peut être hérité pour les membres du rôle propriétaire ; voir Section 21.3.)

Un objet peut se voir affecter un nouveau propriétaire avec la commande ALTER correspondant à l'objet, par exemple

ALTER TABLE nom_table OWNER TO nouveau_propriétaire;

Les superutilisateurs peuvent toujours le faire. Les rôles ordinaires ne peuvent le faire que s'ils sont le propriétaire actuel de l'objet (ou qu'ils héritent des droits du rôle propriétaire) et qu'ils sont capables d'exécuter SET ROLE vers le nouveau rôle propriétaire.

La commande GRANT est utilisée pour accorder des droits. Par exemple, si joe est un rôle et comptes une table, le droit de modifier la table comptes peut être accordé à joe avec :

GRANT UPDATE ON comptes TO joe;

Écrire ALL à la place d'un droit spécifique accorde tous les droits applicables à ce type d'objet.

Le nom de « rôle » spécial PUBLIC peut être utilisé pour donner un droit à tous les rôles du système. De plus, les rôles de type « group » peuvent être configurés pour aider à la gestion des droits quand il y a beaucoup d'utilisateurs dans une base -- pour les détails, voir Chapitre 21.

Pour révoquer un droit précédemment donné, on utilise la commande nommée REVOKE, comme dans l'exemple ci-dessous :

REVOKE ALL ON comptes FROM PUBLIC;

Habituellement, seul le propriétaire de l'objet ou un superutilisateur peuvent accorder ou révoquer les droits sur un objet. Néanmoins, il est possible de donner un droit « avec possibilité de transmission »(« with grant option »), qui donne à celui qui le reçoit le droit de donner ce droit à d'autres. Si cette option est ensuite révoquée, alors tous ceux qui ont reçu ce droit par cet utilisateur(directement ou indirectement via la chaîne des dons) perdent ce droit. Pour les détails, voir les pages de références GRANT et REVOKE.

Le propriétaire d'un objet peut décider de révoquer ses propres droits standards. Par exemple, il peut rendre une table en lecture seule pour eux comme pour les autres. Mais les propriétaires sont toujours traités comme ayant le droit de donner des droits, pour qu'ils puissent toujours retrouver leur anciens droits.

Les droits disponibles sont :

Les droits requis par d'autres commandes sont listés sur la page de référence de la commande.

Par défaut, PostgreSQL accorde des droits sur certains types d'objets à PUBLIC dès la création des objets. Aucun droit n'est accordé à PUBLIC par défaut sur les tables, colonnes de table, séquences, foreign data wrappers, serveurs distants, large objects, schémas, tablespaces et paramètres de configuration. Pour les autres types d'objets, les droits par défaut accordés à PUBLIC sont les suivants : sur les bases de données : les droits CONNECT et TEMPORARY(création de table temporaire) ; sur les fonctions et procédures : le droit EXECUTE  ; et sur les langages et types de données (y compris les domaines) : le droit USAGE. Bien sûr, le propriétaire de l'objet peut révoquer, à l'aide de la commande REVOKE, les droits par défaut comme ceux expressément accordés. (Pour une sécurité maximale, ordonnez REVOKE dans la même transaction que celle qui crée l'objet ; il n'y a alors aucune fenêtre où un autre utilisateur peut utiliser l'objet.) Ces droits par défaut peuvent aussi être remplacés avec la commande ALTER DEFAULT PRIVILEGES.

Tableau 5.1 liste les abréviations à une lettre utilisées pour les types de droits dans les valeurs des ACL (listes de contrôle d'accès). Vous verrez ces lettres dans la sortie des commandes psql plus bas, ou en consultant les colonnes ACL des catalogues système.

Tableau 5.2 résume les droits disponibles pour chaque objet SQL, avec les abréviations ci-dessus. Il affiche aussi la commande psql à utiliser pour consulter les valeurs des droits de chaque type d'objet.

Les droits accordés à un objet particulier sont affichés comme une liste d'entrées aclitem, chacune ayant le format :

grantee=privilege-abbreviation[*].../grantor

Chaque aclitem liste tous les droits d'un rôle qui ont été donnés par un rôle particulier. Les droits spécifiques sont représentés par des abréviations sur une lettre à partir de Tableau 5.1, avec un * ajouté si le droit a été donné avec l'option grant. Par exemple, calvin=r*w/hobbes indique que le rôle calvin a le droit SELECT (r) avec possibilité de transmission (« with grant option ») ainsi que le droit UPDATE (w), sans retransmission possible ; droits accordés tous les deux par le rôle hobbes. Si calvin a aussi des droits sur le même objet accordés par un autre utilisateur, ils apparaîtraient comme une entrée aclitem séparée. Un champ vide dans un aclitem indique PUBLIC.

Par exemple, supposons que l'utilisateur miriam crée une table mytable et fasse :

GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;

alors dans psql, la commande \dp afficherait :

=> \dp mytable
                                   Access privileges
 Schema |  Name   | Type  |   Access privileges    |   Column privileges   | Policies
--------+---------+-------+------------------------+-----------------------+----------
 public | mytable | table | miriam=arwdDxtm/miriam+| col1:                +|
        |         |       | =r/miriam             +|   miriam_rw=rw/miriam |
        |         |       | admin=arw/miriam       |                       |
(1 row)

Si la colonne « Droits d'accès » est vide pour un objet donné, cela signifie que l'objet a les droits par défaut(c'est-à-dire que l'entrée des droits dans les catalogues systèmes est NULL). Les droits par défaut incluent toujours tous les droits pour le propriétaire, et peuvent inclure certains droits pour PUBLIC en fonction du type d'objet comme expliqué plus haut. La première commande GRANT ou REVOKE sur un objet va instancier les droits par défaut (en produisant, par exemple, miriam=arwdDxt/miriam) puis les modifier selon la requête. De manière similaire, des entrées ne sont affichées dans « Droits d'accès à la colonne » que pour les colonnes qui n'ont pas les droits par défaut.(Note : dans ce contexte, on entend par « droits par défaut » les droits par défaut intégrés à PostgreSQL pour le type d'objet. Un objet dont les droits auront été affectés par une commande ALTER DEFAULT PRIVILEGES montrera toujours une entrée de droits explicite qui inclue les effets du ALTER.)

Notez que les droits de transmission (grant option) implicites ne sont pas indiqués dans l'affichage des droits d'accès. Un * n'apparaîtra que si la transmission a été explicitement accordée à quelqu'un.

La colonne « Access privileges » affiche (none) quand les droits de l'objet sont non nuls mais vides. Cela signifie qu'aucun droit n'a été donné, y compris au propriétaire de l'objet -- une situation rare. (Le propriétaire a toujours l'option grant implicite dans ce cas, et peut donc se redonner des droits, mais il n'en a aucun pour l'instant.)