On Tue, Dec 1, 2015 at 3:32 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost <sfr...@snowman.net> wrote: >> > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote: >> >> > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> >> >> It seems weird to not have a dedicated role for pg_switch_xlog. >> >> > >> >> > I didn't add a pg_switch_xlog default role in this patch series, but >> >> > would be happy to do so if that's the consensus. It's quite easy to do. >> >> >> >> Agreed. I am not actually getting why that's part of the backup >> >> actually. That would be more related to archiving, both being >> >> unrelated concepts. But at this point I guess that's mainly a >> >> philosophical split. >> > >> > As David notes, they're actually quite related. Note that in our >> > documentation pg_switch_xlog() is listed in the "Backup Control >> > Functions" table. >> > >> > I can think of a use-case for a user who can call pg_switch_xlog, but >> > not pg_start_backup()/pg_stop_backup(), but I have to admit that it >> > seems rather limited and I'm on the fence about it being a worthwhile >> > distinction. >> >> Sounds too narrow to me. Are we going to have a separate predefined >> role for every security-restricted function to which someone might >> want to grant access? That seems over the top to me. > > I certainly don't want to go down to that level and was, as seen above, > unsure about having pg_switch_xlog() as a differentiated privilege. > Michael, do you still see that as a useful independent capability?
OK, let's do so then by having this one fall under pg_backup. Let's not be my grunting concerns be an obstacle for this patch, and we could still change it afterwards in this release beta cycle anyway based on user feedback. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
