On Tue, Dec 1, 2015 at 3:32 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > * Michael Paquier (michael.paquier@gmail.com) wrote:
>> >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
>> >> > * Michael Paquier (michael.paquier@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