Re: [PATCHES] Users/Groups -> Roles

Fabien,

* Fabien COELHO (coelho(at)cri(dot)ensmp(dot)fr) wrote:
> >I really disagree with you here. I feel it makes much more sense to do
> >this in stages, first user/group -> roles, then roles-per-catalog, which
> >means you can then have both per-catalog 'users' and per-catalog
> >'groups', if you want to limit your view to that.
>
> I don't think that having two kinds of roles (per-cluster and per-catalog)
> would be a practical thing from the user perspective. From the
> implementation point of view, two tables will be needed. If you don't
> create roles directly in the right scope, it will create confusion later.
>
> The two concept need to have two different names so that they can be
> understood. Moreover, a working per-cluster grouping was already
> available. Changing the role scope will be much harder than creating a
> role directly in the good scope.

The two concepts certainly don't need different names to distinguish
them. A simple distinction such as superusers are per-cluster and all
other roles are not would be sufficient. I expect that's the kind of
thing people would be looking for anyway.

> >From the implementation perspective, there is more work at adding
> per-cluster roles and removing per-cluster group and then later try to add
> per-catalog roles than adding per-catalog roles directly without touching
> the existing group stuff.

Having just spent a fair bit of time on the implementation, I have to
disagree with you here.

> So I'm afraid that the opportunity is missed and that per-catalog role
> will never get in. Well, at least you look more optimistic than me;-)

Honestly, this comes across to me the same as saying that because we
have databases we'd never have schemas.

Please outline exactly what you're really looking for. Let's drop the
idea of per-cluster users/groups/roles/whatever and instead consider
what specific capabilities you're looking for. We can then decide if
those capabilities are best provided through per-catalog roles, if
they're already covered with the existing framework, or if there's some
other, better solution.

Thanks,

Stephen