Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/22/17 09:17, Stephen Frost wrote: > >> If we do it via GRANTs instead, then users can easily extend it. > > The intent here is that users will *also* be able to do it via GRANTs if > > they wish to. > > But why not do it with GRANTs in the first place then?
This is akin to asking why do we need GRANT ALL and ALTER DEFAULT PRIVs. Would it be technically possible to make users jump through hoops every time they set up a new system to create their own monitor role that would then have the right set of privileges for *that* version of PG? Yes, but it's not exactly friendly. The whole idea here is that the tool authors will be able to tell the users that they just need to GRANT this one role, not a script of 20 GRANT statements, oh, and that it won't break when doing upgrades. If we make the users run all the statements individually then they'll also have to get an updated script for the next version of PG too because we will have added things that the tools will want access to. Further, they'll have to make sure to install all the contrib modules they want to use before running the GRANT script which is provided, or deal with GRANT'ing the rights out after installing some extension. With the approach that Dave and I are advocating, we can avoid all of that. Contrib modules can bake-in GRANTs to the appropriate roles, upgrades can be handled smoothly even when we add new capabilities which are appropriate, users have a simple and straight-forward way to set up good monitoring, and tool authors will know what permissions are available and can finally have a better answer than "well, just make the monior user superuser if you want to avoid all these complexities." Thanks! Stephen
signature.asc
Description: Digital signature
