Date: Sun, 14 Jun 2020 23:11:02 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Joseph Nahmias <joe@nahmias.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: create database with template doesn't copy database ACL
Message-ID: <20200615031102.GA12121@momjian.us>
References: <159136749445.7029.12571169059565185790@wrigleys.postgresql.org>
 <20200612212951.GB6813@momjian.us>
 <20200614072613.GA21852@nahmias.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200614072613.GA21852@nahmias.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Sun, Jun 14, 2020 at 07:26:13AM +0000, Joseph Nahmias wrote:
> On Fri, Jun 12, 2020 at 05:29:51PM -0400, Bruce Momjian wrote:
> > On Fri, Jun  5, 2020 at 02:31:34PM +0000, PG Doc comments form wrote:
> > > The following documentation comment has been logged on the website:
> > > 
> > > Page: https://www.postgresql.org/docs/11/sql-createdatabase.html
> > > Description:
> > > 
> > > My understanding is that not copying the ACL is the (currently) expected
> > > behavior when issuing CREATE DATABASE newdb WITH TEMPLATE my_tmpl;
> > > It would be useful for the documentation to note this caveat.
> > 
> > Uh, what ACLs are not copied?
> 
> The ACL on the database itself. For example:
> 
> postgres@postgres[[local]#9655]=# CREATE DATABASE acl_template WITH IS_TEMPLATE = 1;
> CREATE DATABASE
> postgres@postgres[[local]#9655]=# REVOKE ALL ON DATABASE acl_template FROM PUBLIC;
> REVOKE
> postgres@postgres[[local]#9655]=# CREATE DATABASE acl_test WITH TEMPLATE = acl_template;
> CREATE DATABASE
> postgres@postgres[[local]#9655]=# SELECT datname, datacl FROM pg_database WHERE datname LIKE 'acl%';
>    datname    |         datacl
> --------------+-------------------------
>  acl_template | {postgres=CTc/postgres}
>  acl_test     |
> (2 rows)
> 
> Here, the ACL on the new acl_test database does NOT match the ACL on the
> acl_template database upon which it is based.

[I am moving this to the hackers list because I am not clear if this is a
documentation problem or a bug.]

Effectively, we have three levels of objects:

	1  global, cluster-wide, e.g., tablespaces, users
	2  database attributes, e.g., database encoding, database tablespace
	3  objects inside of databases

We don't clearly describe it that way though.  Looking at the test:

	psql -a <<END
	ALTER DATABASE acl_template WITH IS_TEMPLATE false;
	DROP DATABASE IF EXISTS acl_template;
	DROP DATABASE IF EXISTS acl_test;
	CREATE DATABASE acl_template WITH IS_TEMPLATE = 1;
	REVOKE ALL ON DATABASE acl_template FROM PUBLIC;
	CREATE DATABASE acl_test WITH TEMPLATE = acl_template;
	SELECT datname, datacl FROM pg_database WHERE datname LIKE 'acl%';
	   datname    |         datacl
	--------------+-------------------------
	 acl_template | {postgres=CTc/postgres}
	 acl_test     | (null)
	END

	$ pg_dump acl_template | grep CONNECT

	$ pg_dump --create acl_template | grep CONNECT
	REVOKE CONNECT,TEMPORARY ON DATABASE acl_template FROM PUBLIC;

	$ pg_dumpall --globals-only | grep CONNECT

	$ pg_dumpall | grep CONNECT
	REVOKE CONNECT,TEMPORARY ON DATABASE acl_template FROM PUBLIC;

it appears database CONNECT and TEMPORARY are treated as database
attributes (2) because they are only dumped when the database is being
created, not by pg_dumpall --globals-only(1) or pg_dump(3).

I am unclear if we should be copying the CONNECT and TEMPORARY
attributes or documenting that CREATE DATABASE does not copy them.

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

  The usefulness of a cup is in its emptiness, Bruce Lee