Thread: Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED
Hi Stephen and Hackers, Moved to -hackers. > Here's a proof-of-concept pretty much untested (it compiles) patch > against HEAD for review of the general approach I'm taking to > merging pg_shadow and pg_group. This is in order to support group > ownership and eventually roles. I have to disagree with your model. Roles are not so simple like you try to describe in your patch. I'm suposing this because your using role* in all of the 'pg_shadow'. What's Role? A set of relations with their respective privileges and a set of users and/or roles. Sometime ago, I drafted a model I think it can be useful. Here it is: Another catalog relation named 'pg_role' with the following members: - rolsysid (role id) - rolname (role name) - rolowner (role owner) - rolmembs[] (list of users that belong to the role) - rolrels[] (list of relations + their permissions) - hasroles (have dependent roles?) where: rolmembs[] is: - userid (user id or group id or role id) rolrels[] is: - relid (relation oid) - rs_privs (privileges) What do we do with 'groups'? Well, we can have three categories of object owners: users, groups and roles. So the 'group owner' can be implemented with this model. What about dependent roles? It will be in 'pg_depend'. Advantages: 1. Don't require changing the actual catalog model. Just an increment. 2. Can't introduce too much overhead. Once roles are in another catalog table, we need to search it only if it's required. 3. All serious commercial databases have it. And of course, PostgreSQL community want it too. :-) Disadvantages: 1. Some overhead when checking for roles and dependent roles. Comments and/or ideas? ===== Euler Taveira de Oliveira euler[at]yahoo_com_br __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/
* Euler Taveira de Oliveira (eulerto@yahoo.com.br) wrote: > > Here's a proof-of-concept pretty much untested (it compiles) patch > > against HEAD for review of the general approach I'm taking to > > merging pg_shadow and pg_group. This is in order to support group > > ownership and eventually roles. > > I have to disagree with your model. Roles are not so simple like you > try to describe in your patch. I'm suposing this because your using > role* in all of the 'pg_shadow'. The particular name isn't really important- and don't take it to mean very much... > What's Role? A set of relations with their respective privileges and > a set of users and/or roles. That's a good question- I'm not really very familiar with roles. :) I'm honestly more interested in group ownership... > Advantages: > 1. Don't require changing the actual catalog model. Just an increment. I'm not sure what the value of this is.. > 2. Can't introduce too much overhead. Once roles are in another catalog > table, we need to search it only if it's required. ok. > 3. All serious commercial databases have it. And of course, PostgreSQL > community want it too. :-) Well, yes, we want roles, we're discussing implementations though, and I don't see this as an 'advantage' of your approach. :) > Disadvantages: > 1. Some overhead when checking for roles and dependent roles. It was Tom's suggestion that pg_shadow and pg_group be merged to guarntee unique in the 'id's, which needs to be there unless you want to change pg_object (iirc? whatever table it is) to handle additional information about what kind of 'id' it is (role, user or group). Stephen
Hi Stephen,
> > I have to disagree with your model. Roles are not so simple like
> you
> > try to describe in your patch. I'm suposing this because your using
> > role* in all of the 'pg_shadow'.
>
> The particular name isn't really important- and don't take it to mean
> very much...
>
OK. So let it 'use*'.
> > What's Role? A set of relations with their respective privileges
> and
> > a set of users and/or roles.
>
> That's a good question- I'm not really very familiar with roles. :)
> I'm
> honestly more interested in group ownership...
>
OK. Thinking better, keep up your work. I'm going to keep my eyes on
it.
=====
Euler Taveira de Oliveira
euler[at]yahoo_com_br
_______________________________________________________
Yahoo! Acesso Grátis - Instale o discador do Yahoo! agora. http://br.acesso.yahoo.com/ - Internet rápida e grátis
Euler Taveira de Oliveira <eulerto@yahoo.com.br> writes:
> What's Role? A set of relations with their respective privileges and
> a set of users and/or roles.
Huh? How did relations get into it?
> What do we do with 'groups'? Well, we can have three categories of
> object owners: users, groups and roles. So the 'group owner' can be
> implemented with this model.
Why wouldn't we fold all three into one concept? In particular, I
really fail to see why we'd still keep a separate notion of groups.
regards, tom lane