From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Additional role attributes && superuser review |
Date: | 2014-10-16 12:29:51 |
Message-ID: | CABUevEyxdJE3kh5b0s7hjLd0VyG4B9ksmpX9PVzeD13t3Fh=uA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Oct 16, 2014 1:59 PM, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
>
> * Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> > On 15 October 2014 06:22, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > BACKUP:
> > > pg_start_backup()
> > > pg_stop_backup()
> > > pg_switch_xlog()
> > > pg_create_restore_point()
> >
> > Yes, but its more complex. As Jim says, you need to include pg_dump,
> > plus you need to include the streaming utilities, e.g. pg_basebackup.
>
> I'd rather have more, simpler, role attributes than one 'catch-all'.
>
> Once I understand what "include pg_dump" and "include pg_basebackup"
> mean, I'd be happy to work on adding those.
>
Include pg_basebackup would mean the replication protocol methods for base
backup and streaming. Which is already covered by the REPLICATION flag.
But in think it's somewhat useful to separate these. Being able to execute
pg_stop_backup allows you to break somebody else's backup currently
running, which pg_basebackup is safe against. So being able to call those
functions is clearly a higher privilege than being able to use
pg_basebackup.
/Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2014-10-16 12:46:25 | Re: Additional role attributes && superuser review |
Previous Message | Stephen Frost | 2014-10-16 12:21:53 | Re: Additional role attributes && superuser review |