From 70a7732007bc4689f4c7a44e738eb2d892dac1e3 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 19 Feb 2020 16:59:14 -0500 Subject: Remove support for upgrading extensions from "unpackaged" state. 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 --- doc/src/sgml/contrib.sgml | 16 ------------- doc/src/sgml/extend.sgml | 27 --------------------- doc/src/sgml/ref/create_extension.sgml | 43 +++------------------------------- 3 files changed, 3 insertions(+), 83 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml index 08bb110b515..261a559e81c 100644 --- a/doc/src/sgml/contrib.sgml +++ b/doc/src/sgml/contrib.sgml @@ -87,22 +87,6 @@ CREATE EXTENSION module_name; target schema, which in turn defaults to public. - - If your database was brought forward by dump and reload from a pre-9.1 - version of PostgreSQL, and you had been using the pre-9.1 - version of the module in it, you should instead do - - -CREATE EXTENSION module_name FROM unpackaged; - - - This will update the pre-9.1 objects of the module into a proper - extension object. Future updates to the module will be - managed by . - For more information about extension updates, see - . - - Note, however, that some of these modules are not extensions in this sense, but are loaded into the server in some other way, for instance diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml index ffe068b0c4c..9ec1af780b1 100644 --- a/doc/src/sgml/extend.sgml +++ b/doc/src/sgml/extend.sgml @@ -916,33 +916,6 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr target (new) version. - - The update mechanism can be used to solve an important special case: - converting a loose collection of objects into an extension. - Before the extension mechanism was added to - PostgreSQL (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 CREATE EXTENSION 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 ALTER - EXTENSION ADD 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. CREATE - EXTENSION supports this case with its FROM old_version option, which causes it to not run the - normal installation script for the target version, but instead the update - script named - extension--old_version--target_version.sql. - The choice of the dummy version name to use as old_version is up to the extension author, though - unpackaged 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. - - ALTER EXTENSION is able to execute sequences of update script files to achieve a requested update. For example, if only diff --git a/doc/src/sgml/ref/create_extension.sgml b/doc/src/sgml/ref/create_extension.sgml index d76ac3e18d0..6a21bff2f62 100644 --- a/doc/src/sgml/ref/create_extension.sgml +++ b/doc/src/sgml/ref/create_extension.sgml @@ -24,7 +24,6 @@ PostgreSQL documentation CREATE EXTENSION [ IF NOT EXISTS ] extension_name [ WITH ] [ SCHEMA schema_name ] [ VERSION version ] - [ FROM old_version ] [ CASCADE ] @@ -48,8 +47,9 @@ CREATE EXTENSION [ IF NOT EXISTS ] extension_name The user who runs CREATE EXTENSION 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. @@ -141,33 +141,6 @@ CREATE EXTENSION [ IF NOT EXISTS ] extension_name - - old_version - - - FROM old_version - must be specified when, and only when, you are attempting to install - an extension that replaces an old style module that is just - a collection of objects not packaged into an extension. This option - causes CREATE EXTENSION to run an alternative installation - script that absorbs the existing objects into the extension, instead - of creating new objects. Be careful that SCHEMA specifies - the schema containing these pre-existing objects. - - - - The value to use for old_version 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 - PostgreSQL, use unpackaged - for old_version when - updating a module to extension style. - - - - CASCADE @@ -220,16 +193,6 @@ CREATE EXTENSION [ IF NOT EXISTS ] extension_name CREATE EXTENSION hstore; - - - Update a pre-9.1 installation of hstore into - extension style: - -CREATE EXTENSION hstore SCHEMA public FROM unpackaged; - - Be careful to specify the schema in which you installed the existing - hstore objects. - -- cgit v1.2.3