Re: [PATCHES] Users/Groups -> Roles

Dear Stephen,

> 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.

I think from a conceptual point of view that the ability to manage
permissions at the database level (per-catalog role) is a good thing (tm)
for everybody. The privilege management is about a catalog, so it better
to have it in the catalog.

My personnal uses are two fold :

- for teaching purposes, I can give every student his/her database
and have her/him practice db privileges independently. They
can create their own roles and do whatever with them...

- for administration purposes, different databases have different
requirements, and maybe different kind of role "readonly",
"modifiable", "fulladmin" which could be attributed independently in
each database.

Basically, I want to be able to delegate to someone the right management
for one database, including the creation of roles and so on, without
interference from one database to another.

So as to illustrate what I call an interference: say you have 2 databases
which where on 2 clusters and you want to transfert them into the same
cluster. If the same role name was used in both database, you may have
interferences, people being given rights on one database and applying them
to the other if they can connect to it.

> 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.

One inelegant solution is to prefix the role names with the database name,
but that is just a discipline and cannot be inforced. I think we can do better.

If you're right that having both "per-catalog" and "per-cluster" role with
some flag would be accepted into postgresql, then that will be fine with
me. I'll just argue for the per-catalog roles to be the default.

Thanks for all your answers, have a nice day,

--
Fabien.