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

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

Reply via email to