Why did PostgreSQL merge users and groups into rol

Question

From the PostgreSQL docs:

The concept of roles subsumes the concepts of "users" and "groups". In PostgreSQL versions before 8.1, users and groups were distinct kinds of entities, but now there are only roles. Any role can act as a user, a group, or both.

Why did they make this change in 8.1?

Perhaps it's easier from the C coders point of view, with a single Role class (struct)?

More details:

CREATE USER is equivalent to CREATE ROLE except that CREATE USER gives the LOGIN permission to the user/role.

(I'm about to design a permission system for my webapp, hence I'm interested in this.)

Answer 1

From the manual:

The SQL standard defines the concepts of users and roles, but it regards them as distinct concepts and leaves all commands defining users to be specified by each database implementation. In PostgreSQL we have chosen to unify users and roles into a single kind of entity. Roles therefore have many more optional attributes than they do in the standard.

Answer 2

I found this thread in the PostgreSQL-Hackers list, from June 6, 2003, that in the end suggests that users and groups and roles be consolidated. (Thanks Craig Ringer for suggesting that I check the pgsql-hackers list archives.)

Here are some benefits mentioned (those that I found).

allow groups to have groups as members

the ACL code would be simplified

the GRANT/REVOKE syntax and the display format for ACL lists could be simplified, since there'd be no need for a syntactic marker as to whether a given name is a user or a group.

In some circumstances I could see it making sense to allow logging in directly as a group/role/whatchacallit

This would also solve the problem that information_schema views will show only owned objects

[makes it easier to] representing privileges granted to groups [since you'd simply reuse the role related code?]

Answer 3

Having a distinction between users and groups doesn't gain you anything.

AFAIK the motivation for changing it was to simplify uses like:

• One user masquerading as another, eg a superuser simulating a reduced permissions user. With unified roles this becomes just another change of current role, no different to changing primary group.

• Groups that are members of other groups to implement granular access permissions.

If you want the details, though, you're best off checking out the archives of the pgsql-hackers list for the period, and the git history (converted from CVS).

Answer 4

The merge has many advantages and no disadvantages. For instance, you can now seamlessly convert a "user" to a "group" and vice versa by adding / removing the LOGIN privilege.

ALTER ROLE myrole LOGIN;
ALTER ROLE myrole NOLOGIN;

Or you can GRANT membership in any other login ("user") or non-login role ("group") to a role:

GRANT joe TO sue;

You can still:

CREATE USER james;

That's just a role with login privilege now. Or:

CREATE GROUP workers;

That's effectively the same as CREATE ROLE now.

The manual has it all.