| From: | walther(at)technowledgy(dot)de |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fixing CREATEROLE |
| Date: | 2022-11-28 20:08:17 |
| Message-ID: | 9a1aaf58-1244-3c20-9758-411066666c8d@technowledgy.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark Dilger:
> Robert's patch tries to deal with the (possibly unwanted) role membership by setting up defaults to mitigate the effects, but that is more confusing to me than just de-conflating role membership from role administration, and giving role creators administration over roles they create, without in so doing giving them role membership. I don't recall enough details about how hard it is to de-conflate role membership from role administration, and maybe that's a non-starter for reasons I don't recall at the moment.
Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That
should allow role administration, without actually granting membership
in that role, yet, right?
Best,
Wolfgang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-11-28 20:28:39 | Re: fixing CREATEROLE |
| Previous Message | Mark Dilger | 2022-11-28 20:02:34 | Re: fixing CREATEROLE |