| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fixing CREATEROLE |
| Date: | 2022-11-23 21:40:44 |
| Message-ID: | 3746172.1669239644@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wed, Nov 23, 2022 at 2:18 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Either way, I'm not quite sure what the benefit of converting these
>> things to predefined roles is.
> Specifically, you gain inheritance/set and "admin option" for free.
Right: the practical issue with CREATEROLE/CREATEDB is that you need
some mechanism for managing who can grant those privileges. The
current answer isn't very flexible, which has been complained of
repeatedly. If they become predefined roles then we get a lot of
already-built-out infrastructure to solve that, instead of having to
write even more single-purpose logic. I think it's a sensible future
path, but said lack of flexibility hasn't yet spurred anyone to do it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-11-23 21:41:35 | Re: fixing CREATEROLE |
| Previous Message | David G. Johnston | 2022-11-23 21:27:55 | Re: fixing CREATEROLE |