On Sat, Mar 25, 2017 at 12:30 PM, Dave Page <dp...@pgadmin.org> wrote: > Right - and if a user doesn't like it, they can easily just not use the > default role and create their own alternative instead.
OK, I see the points that both of you are making and I admit that they've got some validity to them. Let me make a modest proposal. Suppose we define the pg_monitor role as strictly a bundle of privileges that could be granted individually if desired, and similarly define pg_read_all_settings and pg_read_all_stats as roles that are strictly recognized by the code, without any grants. So instead of this: GRANT EXECUTE ON FUNCTION pgstatindex(regclass) TO pg_read_all_stats; We'd instead do this: GRANT EXECUTE ON FUNCTION pgstatindex(regclass) TO pg_monitor; (and similarly for all other GRANT statements that appear in the patch) So, if you want, you can give somebody pg_read_all_stats, enhancing their access to functions to which they already have access, but deny them execute access on some of the individual functions. The permissions with which pg_monitor ends up are unchanged, but somebody creating their own role has a bit more freedom to customize what it can do. I still don't have much confidence in the theory that every monitoring solution ever will want the same privileges, but if we unbundle things as much as we reasonably can, then the worst thing that happens if pg_monitor turns out to be not what everyone wants is that some people do it a different way instead. Which as you say is not that bad. -- 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
