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/