* Euler Taveira de Oliveira ([EMAIL PROTECTED]) 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
signature.asc
Description: Digital signature
