On Wed, Mar 22, 2017 at 7:48 AM, Dave Page <dp...@pgadmin.org> wrote:
>> I'd be inclined to skip the rest of
>> this. If an individual user wants to grant that bundle of privileges
>> to a role, they can do it with or without pg_monitor.
> GRANT cannot be used in all cases, as some of the functions changed
> have hard-coded superuser checks. In those cases, I've added
> pg_monitor membership to the permission checks in the C code.
Oh. Well, why not just control access using the permissions checking
mechanism entirely, without hardcoding any OID?
> The reason for having the role is to minimise the amount of work
> required by the user to setup a role for the purposes of monitoring
> the server. This is a practice which is seen in other DBMSs for
> With the patch, complex monitoring systems can easily be setup with
> something like:
> CREATE ROLE monitoring_user LOGIN;
> GRANT pg_monitor TO monitoring_role;
> Without, the users setting up their monitoring system will have to run
> a much more complex set of GRANTs, almost certainly requiring
But that script is easy to provide, probably not very long, and could
be bundled in an extension if it's helpful. I'm wary of committing
ourselves to a specific decision about what pg_monitor includes; that
seems like it could result in endless future litigation every time
somebody wants to make a change. In contrast, nobody's going to have
any question at all about the remit of pg_read_all_settings.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: