On Sat, Jul 02, 2022 at 08:45:50AM -0400, Robert Haas wrote: > I don't think there is a whole lot of point in replacing role-level > flags with predefined roles that work exactly the same way. Maybe > there is some point, but I'm not excited about it. The problem with > these settings in my opinion is that they are too monolithic. Either > you can create any role with basically any privileges or you can > create no roles at all. Either you are a superuser and can bypass all > permissions checks or you are not and can't bypass any permissions > checks.
Okay. I see. >> 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. > > I think it'd be hard to do that if WITH INHERIT DEFAULT is actually > state stored in the catalog. Maybe I should revise this again so that > the catalog column is just true or false, and the role-level property > only sets the default for future grants. That might be more like what > Tom had in mind originally. I was thinking that when DEFAULT was removed, pg_dump would just need to generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older versions. Using the role-level property as the default for future grants seems a viable strategy, although it would break backward compatibility. For example, if I create a NOINHERIT role, grant a bunch of roles to it, and then change it to INHERIT, the role won't begin inheriting the privileges of the roles it is a member of. Right now, it does. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
