> On Nov 22, 2022, at 2:02 PM, Robert Haas <robertmh...@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 WITH INHERIT false WITH SET false"
doesn't seem too unwieldy, and has the merit that it can be read and understood
without reference to hidden parameters. Forcing this to be explicit should be
safer if these statements ultimately make their way 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't want 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
