Movatterモバイル変換

It is frequently convenient to group users together to ease management of privileges: that way, privileges can be granted to, or revoked from, a group as a whole. InPostgreSQL this is done by creating a role that represents the group, and then grantingmembership in the group role to individual user roles.

To set up a group role, first create the role:

CREATE ROLEname;

Typically a role being used as a group would not have theLOGIN attribute, though you can set it if you wish.

Once the group role exists, you can add and remove members using theGRANT andREVOKE commands:

GRANTgroup_role TOrole1, ... ;REVOKEgroup_role FROMrole1, ... ;

You can grant membership to other group roles, too (since there isn't really any distinction between group roles and non-group roles). The database will not let you set up circular membership loops. Also, it is not permitted to grant membership in a role toPUBLIC.

The members of a group role can use the privileges of the role in two ways. First, member roles that have been granted membership with theSET option can doSET ROLE to temporarily“become” the group role. In this state, the database session has access to the privileges of the group role rather than the original login role, and any database objects created are considered owned by the group role not the login role. Second, member roles that have been granted membership with theINHERIT option automatically have use of the privileges of those directly or indirectly a member of, though the chain stops at memberships lacking the inherit option. As an example, suppose we have done:

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;

Immediately after connecting as rolejoe, a database session will have use of privileges granted directly tojoe plus any privileges granted toadmin andisland, becausejoe“inherits” those privileges. However, privileges granted towheel are not available, because even thoughjoe is indirectly a member ofwheel, the membership is viaadmin which was granted usingWITH INHERIT FALSE. After:

SET ROLE admin;

the session would have use of only those privileges granted toadmin, and not those granted tojoe orisland. After:

SET ROLE wheel;

the session would have use of only those privileges granted towheel, and not those granted to eitherjoe oradmin. The original privilege state can be restored with any of:

SET ROLE joe;SET ROLE NONE;RESET ROLE;

The role attributesLOGIN,SUPERUSER,CREATEDB, andCREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actuallySET ROLE to a specific role having one of these attributes in order to make use of the attribute. Continuing the above example, we might choose to grantCREATEDB andCREATEROLE to theadmin role. Then a session connecting as rolejoe would not have these privileges immediately, only after doingSET ROLE admin.

To destroy a group role, useDROP ROLE:

DROP ROLEname;

Any memberships in the group role are automatically revoked (but the member roles are not otherwise affected).