On Tue, 2006-07-18 at 07:31 -0600, Michael Fuhr wrote: > On Tue, Jul 18, 2006 at 01:45:01PM +0200, Rafal Pietrak wrote: > > Any one knows, why do I have to explicitly SET ROLE, when I try to > > exercise the group priviledge of role creation, while I don't need that > > when accessing tables? Is this a feature, or a bug? > > http://www.postgresql.org/docs/8.1/interactive/role-membership.html > > "The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can > be thought of as special privileges, but they are never inherited > as ordinary privileges on database objects are. You must actually > SET ROLE to a specific role having one of these attributes in order > to make use of the attribute. Continuing the above example, we > might well choose to grant CREATEDB and CREATEROLE to the admin > role. Then a session connecting as role joe would not have these > privileges immediately, only after doing SET ROLE admin."
Thenx. So it's a feature (it is documented). My appology if the following question is naive, but digging it a bit more: Is it a feature, because it should be that way.... why? (standard says so?) ...or it's a feature because it's documented: "Although we'd like it to work like priviledges work on tables, current server-side framework does not allow us to impolement it that way." In other words: 1) is the discrepancy by design (why?) or 2) is it by accident - just results from development history. -- -R ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
