Re: [PATCHES] Users/Groups -> Roles
От | Fabien COELHO |
---|---|
Тема | Re: [PATCHES] Users/Groups -> Roles |
Дата | |
Msg-id | Pine.LNX.4.63.0507041133440.10333@sablons.cri.ensmp.fr обсуждение исходный текст |
Ответ на | Re: [PATCHES] Users/Groups -> Roles (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Dear Tom, > We probably need to think a bit harder about the meaning of CREATEROLE > though. Right now it gives free license not only to create roles but > to alter any property of existing roles. This seems appropriate if you > think of it as a "safer form of superuser", which is how I was thinking > of it. It would be too powerful for Fabien's situation though. Yes. ISTM it would be a good thing to separate - sysadmin issues (create a user that can connect - pg_hba.conf) and - dbadmin issues (manage permission on data in a catalog). The first item is the current pg superuser. I envision the second item as being a property of the database (catalog) OWNER, which can do whatever he/she wants at home, but should not bother others. So there is a need for a limited 'createrole' ability (simple roles that cannot be users (?), and avoid name space collision). This is better for teaching, but also for any service provider which would host many users and databases, and would like to transfer them. If you want to delegate data access privileges to someone, it is better to have that restricted to the catalog to avoid name-space collision. The same issue arises when moving a database from one cluster to another where some role names may already be used. That is the kind of think I also need to do as a dbadmin. If one take a conceptual perspective, database access privilege management is a catalog-related task, so it seems better to have that in the catalog. So I think all points that roles are better (more useful) per-catalog than per-cluster. If you just want to claim that 'pg has roles', you can do the marketing with per-cluster roles;-) If you want them more useful, you need them per-catalog. -- Fabien.
В списке pgsql-hackers по дате отправления: