From: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
---|---|
To: | Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: REVOKE [ADMIN OPTION FOR] ROLE |
Date: | 2015-07-29 11:06:34 |
Message-ID: | CAAS3tyJ2HaZtCSpoctEOfKK7JQ2DO7DXQwF_GMNwUU3+dnBr-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 28, 2015 at 10:51 AM, Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> wrote:
>
> Well, I looked into a draft of SQL:2003. It basically says that "cascade"
> for <revoke role statement> must behave the same way as for <revoke
> privilege statement>. That is, from standard's point of view we have a code
> issue.
>
> Still I doubt about usefulness of this behavior. Do we really need it in
> PostgreSQL?
I think it's useful, as long as there are use-cases where instead of
granting privileges on the specific classes of database objects (i.e.
SELECT on all tables in a given schema) a role is granted instead
which 'accumulates' those privileges. This is the case in our
environment, and, while we are not using ADMIN OPTION, I can imagine
it might be used in order to 'delegate' assignment of privileges from
the central authority to responsible sub-authorities in different
departments. Then, if you need to revoke those (i.e. because the
structure of departments had changed), it's enough to REVOKE ..FROM..
CASCADE instead of getting through each individual assignment case.
Kind regards,
--
Oleksii
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-07-29 11:39:49 | Re: LWLock deadlock and gdb advice |
Previous Message | Ashutosh Bapat | 2015-07-29 10:58:29 | Re: Transactions involving multiple postgres foreign servers |