On Thu, Dec 31, 2015 at 4:26 PM, Noah Misch <n...@leadboat.com> wrote: > On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote: >> * Noah Misch (n...@leadboat.com) wrote: >> I disagree that we would. Having a single >> set of default roles which provide a sensible breakdown of permissions >> is a better approach than asking every administrator and application >> developer who is building tools on top of PG to try and work through >> what makes sense themselves, even if that means we have a default role >> with a small, or even only an individual, capability. > > The proposed pg_replication role introduces abstraction that could, as you > hope, spare a DBA from studying sets of functions to grant together. The > pg_rotate_logfile role, however, does not shield the DBA from complexity. > Being narrowly tied to a specific function, it's just a suboptimal spelling of > GRANT. The gap in GRANT has distorted the design for these predefined roles. > I do not anticipate a sound design discussion about specific predefined roles > so long as the state of GRANT clouds the matter.
As the patch stands, the system roles that are just close to synonyms of GRANT/REVOKE are the following: - pg_file_settings, which works just on the system view pg_file_settings and the function pg_show_all_file_settings(). - pg_rotate_logfile as mentioned already. - pg_signal_backend, which is just checked once in pg_signal_backend Based on those concerns, it looks clear that they should be shaved off from the patch. >> > To summarize, I think the right next step is to resume designing pg_dump >> > support for system object ACLs. I looked over your other two patches and >> > will >> > unshelve those reviews when their time comes. >> >> To be clear, I don't believe the two patches are particularly involved >> with each other and don't feel that one needs to wait for the other. > > Patch 2/3 could stand without patch 3/3, but not vice-versa. It's patch 2/3 > that makes pg_dumpall skip ^pg_ roles, and that must be in place no later than > the first patch that adds a predefined ^pg_ role. I am a bit confused by this statement, and I disagree with Stephen's point as well. It seems to me that 2/3 exists *because* 3/3 is here. Why would we want to restrict the role names that can be used if we are not going to introduce some system roles that are created at bootstrap? -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers