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 > usability. > > 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 > scripting. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
