mirror of
https://github.com/postgres/postgres.git
synced 2025-08-31 17:02:12 +03:00
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
This commit is contained in:
@@ -47,14 +47,25 @@ CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Loading an extension requires the same privileges that would be
|
||||
required to create its component objects. For most extensions this
|
||||
means superuser or database owner privileges are needed.
|
||||
The user who runs <command>CREATE EXTENSION</command> becomes the
|
||||
owner of the extension for purposes of later privilege checks, as well
|
||||
as the owner of any objects created by the extension's script.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Loading an extension ordinarily requires the same privileges that would
|
||||
be required to create its component objects. For many extensions this
|
||||
means superuser privileges are needed.
|
||||
However, if the extension is marked <firstterm>trusted</firstterm> in
|
||||
its control file, then it can be installed by any user who has
|
||||
<literal>CREATE</literal> privilege on the current database.
|
||||
In this case the extension object itself will be owned by the calling
|
||||
user, but the contained objects will be owned by the bootstrap superuser
|
||||
(unless the extension's script explicitly assigns them to the calling
|
||||
user). This configuration gives the calling user the right to drop the
|
||||
extension, but not to modify individual objects within it.
|
||||
</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
Reference in New Issue
Block a user