| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Role Self-Administration |
| Date: | 2021-10-08 22:30:47 |
| Message-ID: | 576BE406-869E-46B7-BEBB-15F46181BBD4@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Oct 7, 2021, at 7:44 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> I don't actually think REVOKE ROLE CASCADE must not fail, nor do I see
> that as explicit in anything you quote above.
I don't see that myself, but I thought that you would, given your other statements about how we shouldn't take a spec requirement to do X and turn it into doing X+Y, because the user wouldn't be expecting Y. So I thought that if DROP ROLE bob was defined in the spec to basically just do REVOKE bob FROM EVERYBODY, and if the CASCADE version of that wasn't supposed to fail, then you'd say that DROP ROLE bob CASCADE wasn't supposed to fail either. (Failing is the unexpected action Y that I expected your rule to prohibit.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | wenjing | 2021-10-09 07:41:26 | Re: [Proposal] Global temporary tables |
| Previous Message | Bharath Rupireddy | 2021-10-08 22:26:29 | Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function? |