Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: 12 to 13 migration, the privs error with pg_pltemplate
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: <20201211203634.GB16415@tamriel.snowman.net>
Date: Fri, 11 Dec 2020 14:04:34 -0700
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1D171AD-F02C-4D78-8152-11329B21E372@elevated-dev.com>
References: <20201211203634.GB16415@tamriel.snowman.net>
To: Stephen Frost <sfrost@snowman.net>
Precedence: bulk

> On Dec 11, 2020, at 1:36 PM, Stephen Frost <sfrost@snowman.net> wrote:
>=20
> Yes, I specifically asked if you were looking at the correct database
> previously, because it matters:

At that time I thought I had run the original REVOKE command in the =
target database, and then tried ALTER DEFAULT PRIVILEGES in postgres. I =
was probably mistaken.

> I'm pretty sure none of this has anything to do with DEFAULT =
PRIVILEGES
> as those only actually apply when a new table is created (and not from =
a
> template database), and that's just never the case with any PG catalog
> tables.

So the fact that default privs were set on the system catalogs was =
inappropriate, but harmless in this case?

> What might be useful to point out is that only a superuser can change
> the privileges associated with PG catalog tables and that you really
> should be careful who you grant superuser privileges to.

Yes, that's one thing I took care of earlier this year: change our =
processes such that we were able to remove superuser from the =
commonly-used service accounts.=