Date: Thu, 17 Dec 2020 13:40:17 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Scott Ribe <scott_ribe@elevated-dev.com>,
	Pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: 12 to 13 migration, the privs error with pg_pltemplate
Message-ID: <20201217184017.GA23245@momjian.us>
References: <074FE83A-E924-4787-9E68-27EB9CE142B3@elevated-dev.com>
 <3264512.1607456932@sss.pgh.pa.us>
 <154608A6-0F38-4BE8-B3F4-3E3308691F91@elevated-dev.com>
 <2BD26D52-19B8-42CD-860D-B9AE21AF5C61@elevated-dev.com>
 <3632844.1607534358@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3632844.1607534358@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Wed, Dec  9, 2020 at 12:19:18PM -0500, Tom Lane wrote:
> Scott Ribe <scott_ribe@elevated-dev.com> writes:
> > Any other suggestions? What could possibly be triggering this GRANT?
> 
> Ah, I'm sorry, I pointed you at the wrong catalog entirely.  It's
> not pg_default_acl that controls this, it's pg_init_privs.  I believe
> what pg_dump is doing is emitting GRANT commands that replicate
> the difference between pg_pltemplate's current actual privileges and
> what is shown for it in pg_init_privs.  So you need to make those
> two things match, in whichever way is easiest.

Should pg_dump or pg_upgrade be detecting and reporting these things,
rather than requiring this analysis by the user?

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

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