On 11/06/2014 03:31 AM, Robert Haas wrote:
[snip]
We haven't reached consensus on this one yet and I didn't want it to fall
too far off the radar.
Here is what I summarize as the current state of the discussion:
1. Syntax:
ALTER ROLE <role> { ADD | DROP } CAPABILITY <capability>
Though a bit late to this thread, I would like to request comments on
potentially beneficial new roles ?? and/or capabilities which I have
recently found needing myself.
The suggested syntax looks intuitive and potentially very flexible.
I'll try to summarize up what I recall from the thread plus my own
itchs, to try and get others to comment and expand on the matter.
We currently have:
* SUPERUSER / CREATEUSER
* CREATEDB
* CREATEROLE
* LOGIN
* REPLICATION
(plus INHERITS and ADMIN options, of course)
It has also been suggested to include a
* BACKUP role (capability?) i.e. ability to take an snapshot and
read all relations, views, triggers and functions (even bypassing RLS)
and the catalog in order to produce a full, consistent dump of the whole
cluster.
and I seem to recall something along the lines of
* AUDIT, potentially limited to just engage
I am hereby suggesting the addition of a
* MAINTENANCE role, which would be able to perform VACUUM, ANALYZE,
REINDEX *CONCURRENTLY* and REFRESH MATERIALIZED VIEW *CONCURRENTLY* ...
and potentially even ALTER TABLE VALIDATE CONSTRAINT (if we are able to
produce a non-blocking/fully concurrent version)
... which might become very useful for DBAs wishing to use some
password-less roles for scheduled maintenance routines while at the same
time reducing the exposure.
While at it, the replication role might as well gain the ability to
promote/demote a cluster (standby<->active), or shall it be some kind of
FAILOVER role/capability ?
Thanks in advance.
/ J.L.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
