database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Remove support for upgrading extensions from "unpackaged" state.

Browse Source 
Andres Freund pointed out that allowing non-superusers to run
"CREATE EXTENSION ... FROM unpackaged" has security risks, since
the unpackaged-to-1.0 scripts don't try to verify that the existing
objects they're modifying are what they expect.  Just attaching such
objects to an extension doesn't seem too dangerous, but some of them
do more than that.

We could have resolved this, perhaps, by still requiring superuser
privilege to use the FROM option.  However, it's fair to ask just what
we're accomplishing by continuing to lug the unpackaged-to-1.0 scripts
forward.  None of them have received any real testing since 9.1 days,
so they may not even work anymore (even assuming that one could still
load the previous "loose" object definitions into a v13 database).
And an installation that's trying to go from pre-9.1 to v13 or later
in one jump is going to have worse compatibility problems than whether
there's a trivial way to convert their contrib modules into extension
style.

Hence, let's just drop both those scripts and the core-code support
for "CREATE EXTENSION ... FROM".

Discussion: https://postgr.es/m/20200213233015.r6rnubcvl4egdh5r@alap3.anarazel.de
This commit is contained in:
Tom Lane
2020-02-19 16:59:14 -05:00
parent 2f9c46a32b
commit 70a7732007
84 changed files with 55 additions and 2428 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/contrib.sgml
View File

@ -87,22 +87,6 @@ CREATE EXTENSION <replaceable>module_name</replaceable>;
target schema, which in turn defaults to <literal>public</literal>.
</para>
<para>
If your database was brought forward by dump and reload from a pre-9.1
version of <productname>PostgreSQL</productname>, and you had been using the pre-9.1
version of the module in it, you should instead do
<programlisting>
CREATE EXTENSION <replaceable>module_name</replaceable> FROM unpackaged;
</programlisting>
This will update the pre-9.1 objects of the module into a proper
<firstterm>extension</firstterm> object. Future updates to the module will be
managed by <xref linkend="sql-alterextension"/>.
For more information about extension updates, see
<xref linkend="extend-extensions"/>.
</para>
<para>
Note, however, that some of these modules are not <quote>extensions</quote>
in this sense, but are loaded into the server in some other way, for instance

27
doc/src/sgml/extend.sgml
View File

@ -916,33 +916,6 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
target (new) version.
</para>
<para>
The update mechanism can be used to solve an important special case:
converting a <quote>loose</quote> collection of objects into an extension.
Before the extension mechanism was added to
<productname>PostgreSQL</productname> (in 9.1), many people wrote
extension modules that simply created assorted unpackaged objects.
Given an existing database containing such objects, how can we convert
the objects into a properly packaged extension? Dropping them and then
doing a plain <command>CREATE EXTENSION</command> is one way, but it's not
desirable if the objects have dependencies (for example, if there are
table columns of a data type created by the extension). The way to fix
this situation is to create an empty extension, then use <command>ALTER
EXTENSION ADD</command> to attach each pre-existing object to the extension,
then finally create any new objects that are in the current extension
version but were not in the unpackaged release. <command>CREATE
EXTENSION</command> supports this case with its <literal>FROM</literal> <replaceable
class="parameter">old_version</replaceable> option, which causes it to not run the
normal installation script for the target version, but instead the update
script named
<literal><replaceable>extension</replaceable>--<replaceable>old_version</replaceable>--<replaceable>target_version</replaceable>.sql</literal>.
The choice of the dummy version name to use as <replaceable
class="parameter">old_version</replaceable> is up to the extension author, though
<literal>unpackaged</literal> is a common convention. If you have multiple
prior versions you need to be able to update into extension style, use
multiple dummy version names to identify them.
</para>
<para>
<command>ALTER EXTENSION</command> is able to execute sequences of update
script files to achieve a requested update. For example, if only

43
doc/src/sgml/ref/create_extension.sgml
View File

@ -24,7 +24,6 @@ PostgreSQL documentation
CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name</replaceable>
[ WITH ] [ SCHEMA <replaceable class="parameter">schema_name</replaceable> ]
[ VERSION <replaceable class="parameter">version</replaceable> ]
[ FROM <replaceable class="parameter">old_version</replaceable> ]
[ CASCADE ]
</synopsis>
</refsynopsisdiv>
@ -48,8 +47,9 @@ CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name
<para>
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.
owner of the extension for purposes of later privilege checks, and
normally also becomes the owner of any objects created by the
extension's script.
</para>
<para>
@ -141,33 +141,6 @@ CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">old_version</replaceable></term>
<listitem>
<para>
<literal>FROM</literal> <replaceable class="parameter">old_version</replaceable>
must be specified when, and only when, you are attempting to install
an extension that replaces an <quote>old style</quote> module that is just
a collection of objects not packaged into an extension. This option
causes <command>CREATE EXTENSION</command> to run an alternative installation
script that absorbs the existing objects into the extension, instead
of creating new objects. Be careful that <literal>SCHEMA</literal> specifies
the schema containing these pre-existing objects.
</para>
<para>
The value to use for <replaceable
class="parameter">old_version</replaceable> is determined by the
extension's author, and might vary if there is more than one version
of the old-style module that can be upgraded into an extension.
For the standard additional modules supplied with pre-9.1
<productname>PostgreSQL</productname>, use <literal>unpackaged</literal>
for <replaceable class="parameter">old_version</replaceable> when
updating a module to extension style.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>CASCADE</literal></term>
<listitem>
@ -220,16 +193,6 @@ CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name
CREATE EXTENSION hstore;
</programlisting>
</para>
<para>
Update a pre-9.1 installation of <literal>hstore</literal> into
extension style:
<programlisting>
CREATE EXTENSION hstore SCHEMA public FROM unpackaged;
</programlisting>
Be careful to specify the schema in which you installed the existing
<literal>hstore</literal> objects.
</para>
</refsect1>
<refsect1>