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 <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.