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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to