Re: fixing CREATEROLE
От | Robert Haas |
---|---|
Тема | Re: fixing CREATEROLE |
Дата | |
Msg-id | CA+Tgmoa1wHzf4cBaEWapZxTzqqpfgv_crY69B=g0UZ9j-Bs+bg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fixing CREATEROLE (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: fixing CREATEROLE
|
Список | pgsql-hackers |
On Tue, Nov 22, 2022 at 3:01 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > > On Nov 21, 2022, at 12:39 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > I have drafted a few patches to try to improve the situation. > > The 0001 and 0002 patches appear to be uncontroversial refactorings. Patch 0003 looks on-point and a move in the rightdirection. The commit message in that patch is well written. Thanks. > Patch 0004 feels like something that won't get committed. The INHERITCREATEDROLES and SETCREATEDROLES in 0004 seems clunky. I think role properties are kind of clunky in general, the way we've implemented them in PostgreSQL, but I don't really see why these are worse than anything else. I think we need some way to control the behavior, and I don't really see a reasonable place to put it other than a per-role property. And if we're going to do that then they might as well look like the other properties that we've already got. Do you have a better idea? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: