Il est souvent intéressant de grouper les utilisateurs pour faciliter la gestion des droits : de cette façon, les droits peuvent être donnés ou supprimés pour tout un groupe. Dans PostgreSQL, ceci se fait en créant un rôle représentant le groupe, puis en ajoutant les rôles utilisateurs individuels membres de ce groupe.

Pour configurer un rôle en tant que groupe, créez tout d'abord le rôle :

CREATE ROLE nom;

Typiquement, un rôle utilisé en tant que groupe n'aura pas l'attribut LOGIN bien que vous puissiez le faire si vous le souhaitez.

Une fois que ce rôle existe, vous pouvez lui ajouter et lui supprimer des membres en utilisant les commandes GRANT et REVOKE :

GRANT role_groupe TO role1, ... ;
REVOKE role_groupe FROM role1, ... ;

Vous pouvez aussi faire en sorte que d'autres rôles groupes appartiennent à ce groupe (car il n'y a pas réellement de distinction entre les rôles groupe et les rôles non groupe). La base de données ne vous laissera pas configurer des boucles circulaires d'appartenance. De plus, il est interdit de faire en sorte qu'un membre appartienne à PUBLIC.

Les membres d'un rôle groupe peuvent utiliser les droits du rôle de deux façons. Tout d'abord, les rôles membres qui se sont vu attribués l'appartenance avec l'option SET peuvent exécuter SET ROLE pour « devenir » temporairement le rôle groupe. Dans cet état, la session de la base de données a accès aux droits du rôle groupe plutôt qu'à ceux du rôle de connexion original et tous les objets créés sont considérés comme appartenant au rôle groupe, et non pas au rôle utilisé lors de la connexion. Deuxièmement, les rôles membres qui se sont vus attribuer l'appartenance avec l'option INHERIT peuvent automatiquement utiliser les droits des rôles dont ils sont membres directement ou indirectement, bien que la chaîne s'arrête aux rôles sans option d'héritage. Comme exemple, supposons que nous avons lancé les commandes suivantes :

CREATE ROLE joe LOGIN;
CREATE ROLE admin;
CREATE ROLE wheel;
CREATE ROLE island;
GRANT admin TO joe WITH INHERIT TRUE;
GRANT wheel TO admin WITH INHERIT FALSE;
GRANT island TO joe WITH INHERIT TRUE, SET FALSE;

Immédiatement après connexion en tant que joe, la session de la base de données peut utiliser les droits donnés directement à joe ainsi que ceux donnés à admin et island parce que joe « hérite » des droits de admin. Néanmoins, les droits donnés à wheel ne sont pas disponibles parce que, même si joe est un membre indirect de wheel, l'appartenance se fait via admin qui a été donné en utilisant WITH INHERIT FALSE. Après :

SET ROLE admin;

la session aura la possibilité d'utiliser les droits donnés à admin mais n'aura plus accès à ceux de joe or island. Après :

SET ROLE wheel;

la session pourra utiliser uniquement ceux de wheel, mais ni ceux de joe ni ceux de admin. L'état du droit initial peut être restauré avec une des instructions suivantes :

SET ROLE joe;
SET ROLE NONE;
RESET ROLE;

Les attributs LOGIN, SUPERUSER, CREATEDB et CREATEROLE peuvent être vus comme des droits spéciaux qui ne sont jamais hérités contrairement aux droits ordinaires sur les objets de la base. Vous devez réellement utiliser SET ROLE vers un rôle spécifique pour avoir un de ces attributs et l'utiliser. Pour continuer avec l'exemple précédent, nous pourrions très bien choisir de donner les droits CREATEDB et CREATEROLE au rôle admin. Puis, une session connectée en tant que le rôle joe n'aurait pas ces droits immédiatement, seulement après avoir exécuté SET ROLE admin.

Pour détruire un rôle groupe, utilisez DROP ROLE :

DROP ROLE nom;

Toute appartenance à ce rôle est automatiquement supprimée (mais les rôles membres ne sont pas autrement affectés).