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
