* 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? > I don't think we should make it our goal to completely eliminate the > use of SECURITY DEFINER functions for privilege delegation. Of > course, being able to grant privileges directly is nicer, because then > the client code doesn't have to know about it. But I think it's OK, > even good, if the predefined roles cater to the common cases, and the > less common cases aren't handled quite as elegantly. Agreed. Thanks! Stephen
signature.asc
Description: Digital signature