On Tue, Dec 1, 2015 at 9:18 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > 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.
Three weeks later... This thread has not moved a iota. Stephen, are you planning to work more on this patch? It seems that we found a consensus. If nothing happens, I am afraid that the destiny of this patch will be to be returned with feedback, it is the 5th CF where this entry is registered. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
