From: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Additional role attributes && superuser review |
Date: | 2014-11-21 20:38:55 |
Message-ID: | 546FA2DF.4000007@adv-solutions.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-11-21 20:59:26 | Re: RLS with check option - surprised design |
Previous Message | Peter Geoghegan | 2014-11-21 20:38:41 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |