On Fri, Jul 01, 2022 at 02:59:53PM -0400, Robert Haas wrote:
> And here is a patch that makes it work that way. In this version, you
> can GRANT foo TO bar WITH INHERIT { TRUE | FALSE | DEFAULT }, and
> DEFAULT means that role-level [NO]INHERIT property is controlling.
> Otherwise, the grant-level option overrides the role-level option.
I haven't spent a ton of time reviewing the patch yet, but I did read
through it and thought it looked pretty good.
> I have some hesitations about this approach. On the positive side, I
> believe it's fully backward compatible, and that's something to like.
> On the negative side, I've always felt that the role-level properties
> - [NO]INHERIT, [NO]CREATEROLE, [NO]SUPERUSER, [NO]CREATEDB were hacky
> kludges, and I'd be happier they all went away in favor of more
> principled ways of controlling those behaviors. I think that the
> previous design moves us in the direction of being able to eventually
> remove [NO]INHERIT, whereas this, if anything, entrenches it.
+1. As mentioned upthread [0], I think attributes like CREATEROLE,
SUPERUSER, and CREATEDB could be replaced with predefined roles. However,
since role attributes aren't inherited, that would result in a behavior
change. I'm curious what you have in mind. It might be worth spinning off
a new thread for this sooner than later.
> It might even encourage people to add *more* role-level Boolean flags.
> For instance, say we add another grant-level property that controls
> whether or not you can SET ROLE to the granted role. Well, it somebody
> going to then say that, for symmetry with CREATE ROLE .. [NO]INHERIT
> we need CREATE ROLE .. [NO]SETROLE? I think such additions would be
> actively harmful, not only because they add complexity, but also
> because I think they are fundamentally the wrong way to think about
> these kinds of properties.
Perhaps there should just be a policy against adding new role-level
options. Instead, new functionality should be provided via predefined
roles or grant-level options. There is some precedent for this. For
example, VACUUM has several options that are only usable via the
parenthesized syntax, and the unparenthesized syntax is marked deprecated
in the documentation. (Speaking of which, is it finally time to remove the
unparenthesized syntax or add WARNINGs when it is used?) For [NO]INHERIT
and WITH INHERIT DEFAULT, presumably we could do something similar. Down
the road, those would be removed in favor of only using grant-level
options.
[0] https://postgr.es/m/20220602180755.GA2402942%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
