Re: fixing CREATEROLE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: fixing CREATEROLE
Date
Msg-id CA+Tgmoa1wHzf4cBaEWapZxTzqqpfgv_crY69B=g0UZ9j-Bs+bg@mail.gmail.com
Whole thread Raw
In response to Re: fixing CREATEROLE  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: fixing CREATEROLE
List 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 by date:

Previous
From: David Rowley
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans
Next
From: Justin Pryzby
Date:
Subject: Re: Make mesage at end-of-recovery less scary.