Invent "trusted" extensions, and remove the pg_pltemplate catalog.

This patch creates a new extension property, "trusted".  An extension
that's marked that way in its control file can be installed by a
non-superuser who has the CREATE privilege on the current database,
even if the extension contains objects that normally would have to be
created by a superuser.  The objects within the extension will (by
default) be owned by the bootstrap superuser, but the extension itself
will be owned by the calling user.  This allows replicating the old
behavior around trusted procedural languages, without all the
special-case logic in CREATE LANGUAGE.  We have, however, chosen to
loosen the rules slightly: formerly, only a database owner could take
advantage of the special case that allowed installation of a trusted
language, but now anyone who has CREATE privilege can do so.

Having done that, we can delete the pg_pltemplate catalog, moving the
knowledge it contained into the extension script files for the various
PLs.  This ends up being no change at all for the in-core PLs, but it is
a large step forward for external PLs: they can now have the same ease
of installation as core PLs do.  The old "trusted PL" behavior was only
available to PLs that had entries in pg_pltemplate, but now any
extension can be marked trusted if appropriate.

This also removes one of the stumbling blocks for our Python 2 -> 3
migration, since the association of "plpythonu" with Python 2 is no
longer hard-wired into pg_pltemplate's initial contents.  Exactly where
we go from here on that front remains to be settled, but one problem
is fixed.

Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others.

Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us

1 files changed, 1 insertions, 5 deletions

diff --git a/src/bin/pg_upgrade/function.c b/src/bin/pg_upgrade/function.c
index 28638e951ee..d163cb2dde7 100644
--- a/src/bin/pg_upgrade/function.c
+++ b/src/bin/pg_upgrade/function.c
@@ -214,13 +214,9 @@ check_loadable_libraries(void)
 			 * plpython2u language was created with library name plpython2.so
 			 * as a symbolic link to plpython.so.  In Postgres 9.1, only the
 			 * plpython2.so library was created, and both plpythonu and
-			 * plpython2u pointing to it.  For this reason, any reference to
+			 * plpython2u point to it.  For this reason, any reference to
 			 * library name "plpython" in an old PG <= 9.1 cluster must look
 			 * for "plpython2" in the new cluster.
-			 *
-			 * For this case, we could check pg_pltemplate, but that only
-			 * works for languages, and does not help with function shared
-			 * objects, so we just do a general fix.
 			 */
 			if (GET_MAJOR_VERSION(old_cluster.major_version) < 901 &&
 				strcmp(lib, "$libdir/plpython") == 0)