> On Nov 22, 2022, at 2:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> 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?
Whatever behavior is to happen in the CREATE ROLE statement should be spelled out in that statement. "CREATE ROLE bob
WITHINHERIT false WITH SET false" doesn't seem too unwieldy, and has the merit that it can be read and understood
withoutreference to hidden parameters. Forcing this to be explicit should be safer if these statements ultimately make
theirway into dump/restore scripts, or into logical replication.
That's not to say that I wouldn't rather that it always work one way or always the other. It's just to say that I
don'twant it to work differently based on some poorly advertised property of the role executing the command.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
