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.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
