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.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to