Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1qzRjP-00GMy5-BN
	for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Nov 2023 01:15:15 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1qzRiN-008FCd-Ve
	for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Nov 2023 01:14:11 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <bruce@momjian.us>)
	id 1qzRiN-008FCQ-Hb
	for pgsql-hackers@lists.postgresql.org; Sun, 05 Nov 2023 01:14:11 +0000
Received: from momjian.us ([72.94.173.45])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <bruce@momjian.us>)
	id 1qzRiI-004kQr-PR
	for pgsql-hackers@lists.postgresql.org; Sun, 05 Nov 2023 01:14:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us;
	s=2023062407; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
	Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description; bh=HvQAbZAiX/9b435zMvA5vciPH3s1ssH0OcCK78xxyzw=; b=1egjR
	4CN1xY1BZGrSieoyFoaxAYku5aq9sK/pHpHZwCQ//1AP48ZvgNO5NfJVoIESLJJcy1vuGwD6emjfm
	ALnujS/KcUAxB63aSMFqwF0duJGOP4vrdWV/T53KvtpTVcuWoUTt7Q5Mas6tKnNhz1R/Q8u0+RP01
	V8/PP4I03VVLQL1h77jXV88QpxF1avx6yWZCqmnsp6///rUTTHjKVyqBeFvves+MWRe6CenW3EaRU
	ulWeFTWTkoJFh0FYXi0q8ATSoRG23+Z42qHPD4QNxLXqWgNJnX71pwjakHaP+iqXOIiOgLET8dRb2
	XGmNrpFiUsjHvodRQiTWabL/Uus1A==;
Received: from bruce by momjian.us with local (Exim 4.96)
	(envelope-from <bruce@momjian.us>)
	id 1qzRiD-0054tO-1b;
	Sat, 04 Nov 2023 21:14:01 -0400
Date: Sat, 4 Nov 2023 21:14:01 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Michael Banck <mbanck@gmx.net>, David Burns <david.burns@fedex.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Version 14/15 documentation Section "Alter Default Privileges"
Message-ID: <ZUbsWcPypVORlYCg@momjian.us>
References: <4a6f157edc4ae38a2050a5893e6729cbb98113bc.camel@cybertec.at>
 <f898e097dbe5e718ec1a6e977d4dda79a6548abb.camel@cybertec.at>
 <a6671d5651e64fceff340c68dbdc41a9c5098748.camel@cybertec.at>
 <653b841d.a70a0220.17f72.2c12@mx.google.com>
 <7de5f33f49a91d7b30b8c01fe46fc280713ebae1.camel@cybertec.at>
 <653cce08.050a0220.a10fb.7878@mx.google.com>
 <ZUUlmpxzsZMSZ7N_@momjian.us>
 <b227432f87266b680fd6f31e37b202b2fae5d9b6.camel@cybertec.at>
 <ZUaLgyKdfWeh6nlj@momjian.us>
 <244e0f9e3300f165ff578302e942fa3145dedfc7.camel@cybertec.at>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="b1mIoMjw04RHfG1F"
Content-Disposition: inline
In-Reply-To: <244e0f9e3300f165ff578302e942fa3145dedfc7.camel@cybertec.at>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/ZUbsWcPypVORlYCg%40momjian.us>
Precedence: bulk


--b1mIoMjw04RHfG1F
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Nov  4, 2023 at 10:12:42PM +0100, Laurenz Albe wrote:
> On Sat, 2023-11-04 at 14:20 -0400, Bruce Momjian wrote:
> > Yes, I see your point.  Updated patch attached.
> 
> Almost perfect, except:
> 
> +      Change default privileges for objects created by
> +      <replaceable>target_role</replaceable>;  if omitted, the current
> +      role is modified.
> 
> It is not the role that is modified.  Perhaps:
> 
>   [...]; if omitted, the current role is used.

Sure, attached.  Here is the issue I have though, we are really not
changing default privileges for objects created in the future, we are
changing the role _now_ so future objects will have different default
privileges, right?  I think wording like the above is kind of odd.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

--b1mIoMjw04RHfG1F
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="role.diff"

diff --git a/doc/src/sgml/ref/alter_default_privileges.sgml b/doc/src/sgml/ref/alter_default_privileges.sgml
index 8a6006188d..c98091239c 100644
--- a/doc/src/sgml/ref/alter_default_privileges.sgml
+++ b/doc/src/sgml/ref/alter_default_privileges.sgml
@@ -90,23 +90,24 @@ REVOKE [ GRANT OPTION FOR ]
   <para>
    <command>ALTER DEFAULT PRIVILEGES</command> allows you to set the privileges
    that will be applied to objects created in the future.  (It does not
-   affect privileges assigned to already-existing objects.)  Currently,
-   only the privileges for schemas, tables (including views and foreign
-   tables), sequences, functions, and types (including domains) can be
-   altered.  For this command, functions include aggregates and procedures.
-   The words <literal>FUNCTIONS</literal> and <literal>ROUTINES</literal> are
-   equivalent in this command.  (<literal>ROUTINES</literal> is preferred
-   going forward as the standard term for functions and procedures taken
-   together.  In earlier PostgreSQL releases, only the
-   word <literal>FUNCTIONS</literal> was allowed.  It is not possible to set
-   default privileges for functions and procedures separately.)
+   affect privileges assigned to already-existing objects.)   Privileges can be
+   set globally (i.e., for all objects created in the current database), or
+   just for objects created in specified schemas.
+  </para>
+
+  <para>
+   As a non-superuser, you can change default privileges only on objects created
+   by yourself or by roles that you are a member of.  If you alter the default
+   privileges for a role, only objects created by that role will be affected.
+   It is not sufficient to be a member of that role; member roles must use
+   <command>SET ROLE</command> to assume the identity of the role for which
+   default privileges were altered.
   </para>
 
   <para>
-   You can change default privileges only for objects that will be created by
-   yourself or by roles that you are a member of.  The privileges can be set
-   globally (i.e., for all objects created in the current database),
-   or just for objects created in specified schemas.
+   There is no way to change the default privileges for objects created by
+   any role.  You have run <command>ALTER DEFAULT PRIVILEGES</command> for all
+   roles that can create objects whose default privileges should be modified.
   </para>
 
   <para>
@@ -118,6 +119,19 @@ REVOKE [ GRANT OPTION FOR ]
    <command>ALTER DEFAULT PRIVILEGES</command>.
   </para>
 
+  <para>
+   Currently,
+   only the privileges for schemas, tables (including views and foreign
+   tables), sequences, functions, and types (including domains) can be
+   altered.  For this command, functions include aggregates and procedures.
+   The words <literal>FUNCTIONS</literal> and <literal>ROUTINES</literal> are
+   equivalent in this command.  (<literal>ROUTINES</literal> is preferred
+   going forward as the standard term for functions and procedures taken
+   together.  In earlier PostgreSQL releases, only the
+   word <literal>FUNCTIONS</literal> was allowed.  It is not possible to set
+   default privileges for functions and procedures separately.)
+  </para>
+
   <para>
    Default privileges that are specified per-schema are added to whatever
    the global default privileges are for the particular object type.
@@ -136,12 +150,9 @@ REVOKE [ GRANT OPTION FOR ]
     <term><replaceable>target_role</replaceable></term>
     <listitem>
      <para>
-      The name of an existing role of which the current role is a member.
-      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.
+      Change default privileges for objects created by
+      <replaceable>target_role</replaceable>;  if omitted, the current
+      role is used.
      </para>
     </listitem>
    </varlistentry>

--b1mIoMjw04RHfG1F--