On Wed, Nov 8, 2023 at 01:12:24PM +0100, Laurenz Albe wrote: > On Tue, 2023-11-07 at 17:30 -0500, Bruce Momjian wrote: > > You didn't seem to like my SET ROLE suggestion so I removed it. > > I thought that the information that you can use SET ROLE to assume > the identity of another role is correct, but leads a bit too far > in the manual page of ALTER DEFAULT PRIVILEGES.
Agreed, it was a stretch. > > > + <para> > > > + There is no way to change the default privileges for objects created > > > by > > > + arbitrary roles. You have run <command>ALTER DEFAULT > > > PRIVILEGES</command> > > > > I find the above sentence odd. What is its purpose? > > I cannot count how many times I have seen the complaint "I have run ALTER > DEFAULT > PRIVILEGES, and now when some other user creates a table, the permissions are > unchanged". People tend to think that if you omit FOR ROLE, the change > applies to > PUBLIC. I agree we have to be clear, and this is complex, which is why we are struggling. I feel we have to be clear about who is allowed to modify which default privileges, and what default privileges are active during object creation. I ended up basically saying you can modify the default privileges of roles you are member of, but they don't apply at creation time for your own role. I am open to better wording. > Your improved documentation of "target_role" already covers that somewhat, so > if > you don't like the repetition, I'm alright with that. I just thought it might > be worth stating it explicitly. > > I think your patch is fine and ready to go. Thanks. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
