Thread: pgsql: Invent "trusted" extensions, and remove the pg_pltemplate catalo
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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/50fc694e43742ce3d04a5e9f708432cb022c5f0d Modified Files -------------- doc/src/sgml/catalogs.sgml | 122 +-------- doc/src/sgml/ddl.sgml | 8 +- doc/src/sgml/extend.sgml | 37 +++ doc/src/sgml/plpython.sgml | 2 +- doc/src/sgml/ref/create_extension.sgml | 17 +- doc/src/sgml/ref/create_language.sgml | 113 ++------ doc/src/sgml/xplang.sgml | 2 +- src/backend/catalog/Makefile | 4 +- src/backend/catalog/catalog.c | 5 - src/backend/catalog/system_views.sql | 3 +- src/backend/commands/extension.c | 175 ++++++++++-- src/backend/commands/functioncmds.c | 5 +- src/backend/commands/proclang.c | 422 +++++------------------------ src/backend/parser/gram.y | 19 +- src/bin/pg_dump/pg_dump.c | 16 +- src/bin/pg_upgrade/function.c | 6 +- src/include/catalog/catversion.h | 2 +- src/include/catalog/indexing.h | 3 - src/include/catalog/pg_pltemplate.dat | 51 ---- src/include/catalog/pg_pltemplate.h | 52 ---- src/include/catalog/pg_proc.dat | 6 +- src/include/catalog/toasting.h | 3 - src/include/commands/extension.h | 1 + src/include/commands/proclang.h | 11 +- src/pl/plperl/GNUmakefile | 6 +- src/pl/plperl/expected/plperl_setup.out | 66 +++++ src/pl/plperl/plperl--1.0.sql | 21 +- src/pl/plperl/plperl.control | 3 +- src/pl/plperl/plperlu--1.0.sql | 18 +- src/pl/plperl/sql/plperl_setup.sql | 64 +++++ src/pl/plpgsql/src/plpgsql--1.0.sql | 21 +- src/pl/plpgsql/src/plpgsql.control | 3 +- src/pl/plpython/plpy_main.c | 2 +- src/pl/plpython/plpython2u--1.0.sql | 18 +- src/pl/plpython/plpython3u--1.0.sql | 18 +- src/pl/plpython/plpythonu--1.0.sql | 18 +- src/pl/tcl/pltcl--1.0.sql | 13 +- src/pl/tcl/pltcl.control | 3 +- src/pl/tcl/pltclu--1.0.sql | 10 +- src/test/regress/expected/rules.out | 3 +- src/test/regress/expected/sanity_check.out | 1 - 41 files changed, 587 insertions(+), 786 deletions(-)
Re: pgsql: Invent "trusted" extensions, and remove the pg_pltemplatecatalo
From
Michael Paquier
Date:
Hi Tom, On Wed, Jan 29, 2020 at 11:43:16PM +0000, Tom Lane wrote: > 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. morepork, prairiedog and curculio are complaining with the test plperl_setup: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork&dt=2020-01-30%2003%3A40%3A36 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=curculio&dt=2020-01-30%2003%3A30%3A37 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2020-01-29%2023%3A45%3A48 Here is the relevant part: CREATE FUNCTION foo2() returns int language plperl as '2;'; +ERROR: cannot allocate multiple Perl interpreters on this platform +CONTEXT: compilation of PL/Perl function "foo2" -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Jan 29, 2020 at 11:43:16PM +0000, Tom Lane wrote:
>> Invent "trusted" extensions, and remove the pg_pltemplate catalog.
> morepork, prairiedog and curculio are complaining with the test
> plperl_setup:
Yeah, I'm on it. I figure I can fix this without breaking the
point of the test by reconnecting at the right spot(s).
regards, tom lane