From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Additional role attributes && superuser review |
Date: | 2015-01-05 16:49:59 |
Message-ID: | CA+TgmoY8q6-mohzcq58eQUiQs4nQHpxuq8AQUSZO_x4oWv3f7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 24, 2014 at 12:48 PM, Adam Brightwell
<adam(dot)brightwell(at)crunchydatasolutions(dot)com> wrote:
> * BACKUP - allows role to perform backup operations
> * LOGROTATE - allows role to rotate log files
> * MONITOR - allows role to view pg_stat_* details
> * PROCSIGNAL - allows role to signal backend processes
How about just "SIGNAL" instead of "PROCSIGNAL"?
Generally, I think we'll be happier if these capabilities have names
that are actual words - or combinations of words - rather than partial
words, so I'd suggest avoiding things like PROC for PROCESS and AUTH
for AUTHORIZATION.
In this particular case, it seems like the name of the capability is
based off the name of an internal system data structure. That's the
sort of thing that we do not want to expose to users. As far as we
can, we should try to describe what the capability allows, not the
details of how that is (currently) implemented.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2015-01-05 16:50:04 | Re: tracking commit timestamps |
Previous Message | Heikki Linnakangas | 2015-01-05 16:45:22 | Re: [COMMITTERS] pgsql: Change how first WAL segment on new timeline after promotion is |