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 1r0mZA-007oCl-I4
	for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Nov 2023 17:42:12 +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 1r0mZ9-006UQV-1p
	for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Nov 2023 17:42: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 1r0mZ8-006UQM-N2
	for pgsql-hackers@lists.postgresql.org; Wed, 08 Nov 2023 17:42:10 +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 1r0mZ6-005O93-4b
	for pgsql-hackers@lists.postgresql.org; Wed, 08 Nov 2023 17:42: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=3V6UIZyuWxd0/SXslcpfDhzKej0mx+eiPyfCuiu3yPQ=; b=fz/ds
	afoBpurqsQaxzuKvQPu+o9iTZ8tEN6OvfobaWP2iOc00dG1C1oXT0VILffT/8zA1YAercBwhL0Nru
	/3JgcpJKgQF1s3lmV9PKVD/kAyXDrjsKHGChY9jygdX6ygpOZzUt+1XKpkTERx+Aj+zjRvjAMLAma
	lM0Ba154+qlA1+dN0n4n63jQ928kr/47UDLLa8H8tPATlMj3OVR/swSoINO9bSNWxNrB7aEtjTRMD
	6P2KTkaijjKPqvcVWRmi+CgTlgCTTOZcxeMnUyeaEpYhcqYeCFDPod0ypslqtS7uL1KEPJdr5uSYc
	VIc00Uo1aIjilqZNqtPtvZEw7PiLA==;
Received: from bruce by momjian.us with local (Exim 4.96)
	(envelope-from <bruce@momjian.us>)
	id 1r0mZ0-00GPj5-2M;
	Wed, 08 Nov 2023 12:42:02 -0500
Date: Wed, 8 Nov 2023 12:42:02 -0500
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: <ZUvIauBmrx30E6XQ@momjian.us>
References: <ZUUlmpxzsZMSZ7N_@momjian.us>
 <b227432f87266b680fd6f31e37b202b2fae5d9b6.camel@cybertec.at>
 <ZUaLgyKdfWeh6nlj@momjian.us>
 <244e0f9e3300f165ff578302e942fa3145dedfc7.camel@cybertec.at>
 <ZUbsWcPypVORlYCg@momjian.us>
 <ceac8e2df89a5eb1335ad8ce39c6ba0beaeddde3.camel@cybertec.at>
 <ZUkMi9UhnfHyIQMf@momjian.us>
 <06bdd234afabd3144ffaf8e95f42af0f3b38082e.camel@cybertec.at>
 <ZUq6fAsQZsyUAySx@momjian.us>
 <d3dcd30164a4f86588d33013e3bd41d7f576f17f.camel@cybertec.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d3dcd30164a4f86588d33013e3bd41d7f576f17f.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/ZUvIauBmrx30E6XQ%40momjian.us>
Precedence: bulk

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.