On Thu, Feb 18, 2021 at 08:16:13AM +0100, Laurenz Albe wrote:
> On Wed, 2021-02-17 at 15:08 -0500, Jordi Gutiérrez Hermoso wrote:
> > I just had a confusing moment trying to figure out why my roles
> > weren't creating tables the way I was expecting them to. I didn't
> > understand what the `target_role` parameter did. No matter how I try
> > to read this page, I can't see an explanation for that parameter:
> >
> > https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
> >
> > I propose an explanation like the following be added to the
> > `target_role` parameter:
> >
> > This is the role that will create objects with altered default
> > privileges. Note that changes in default privileges aren't
> > inherited, so altering the default privileges of created objects
> > for a parent role will not change the default privileges of
> > objects created by inherited roles.
>
> +1. I cannot count the number of times I have seen people confused by that.
>
> Suggested patch attached.
I see how people can be confused. I wrote this patch, which I think is
simpler than the previously posted one.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/ref/alter_default_privileges.sgml b/doc/src/sgml/ref/alter_default_privileges.sgml
index f1d54f5aa3..8a6006188d 100644
--- a/doc/src/sgml/ref/alter_default_privileges.sgml
+++ b/doc/src/sgml/ref/alter_default_privileges.sgml
@@ -137,7 +137,11 @@ REVOKE [ GRANT OPTION FOR ]
<listitem>
<para>
The name of an existing role of which the current role is a member.
- If <literal>FOR ROLE</literal> is omitted, the current role is assumed.
+ Default access privileges are not inherited, so member roles
+ must use <command>SET ROLE</command> to access these privileges,
+ or <command>ALTER DEFAULT PRIVILEGES</command> must be run for
+ each member role. If <literal>FOR ROLE</literal> is omitted,
+ the current role is assumed.
</para>
</listitem>
</varlistentry>
