Peter Eisentraut <[EMAIL PROTECTED]> writes: > Maybe this is too radical, but why not merge "user" and "group" into one > animal? Both exist to bear privileges. The only difference is that > groups can contain other bearers of privileges, but then a user is just a > special case with zero members. Once you allow groups to have the > possibilities that users currently have (createdb privilege, object > ownership), there is no difference left. Of course, one such "animal" > would be the session user and interact with pg_hba.conf, but that is just > an ID, which may as well be a group.
We could make them essentially the same kind of thing, but include a flag column in the table saying whether anyone is allowed to actually log in as this entity. If the flag isn't on, the entity can own tables and have members and so forth, but it can never be the value of session_user. In some circumstances I could see it making sense to allow logging in directly as a group/role/whatchacallit. In other cases you might want a policy that one must log in as oneself --- compare the common Unix practice that you must 'su' to root, not log in directly as root. So it seems to make sense to allow the login flag to be on or off independently of whether the entity has members. It sounds like a reasonable idea to me. We could preserve backwards compatibility for most client-side code by making pg_shadow and pg_group be views of the merged table. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster