ALTER EXTENSION UPGRADE patch v1 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject ALTER EXTENSION UPGRADE patch v1
Date
Msg-id 87ipy4j45w.fsf@hi-media-techno.com
Whole thread Raw
Responses Re: ALTER EXTENSION UPGRADE patch v1  (David Fetter <david@fetter.org>)
List pgsql-hackers
Hi,

Please find attached the patch to support ALTER EXTENSION UPGRADE,
following exchanges made on this list — we can't really speak about
decisions here, apparently, until commit is done :)

The documentation is available online for easy browsing here:

  http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html

The things we might want to discuss are, AFAIUI:

 - support for upgrading from pre-9.1 extension, or to get from a bunch
   of related pl code to a proper extension in your database

   I've done the code for that to work, the idea is pretty simple and
   relies on the following points.  Please note that the attached patch
   only implements support for upgrading some contrib modules from
   pre-9.1, that's because I'm willing to get some approvement before
   continuing the effort — I foresee no road blocks here.

 - CREATE WRAPPER EXTENSION

   If you want to upgrade an extension, it first has to exists as an
   extension.  When you're wanting to switch to extension, you need a
   way to bootstrap your extension object, because you want an entry in
   the catalogs and you don't want to run the script: it has already
   been run before you decided this would make for an extension.

   This command allows you to register an extension in the catalogs,
   bypassing any script and forcing the version to NULL.

   I'm not sold on the 'WRAPPER' keyword here, I just used an existing
   one in the grammar that looked like a good candidate.  This was the
   best I could find, but IANANS (I am not a native speaker).

 - ALTER EXTENSION ... UPGRADE

   This allows you to upgrade an existing extension, wrapper included.

   The extension author needs to prepare the upgrade scripts, and to
   setup in the control file which to use.  The new extension's version
   is static as the upgrade files you distribute depend on this (think
   packaging here) and so you pick the upgrade script file to execute
   depending only on the currently installed version.

   This picking is made by regular expression matching (using the code
   backing the ~(text, text) operator), and supports null as a special
   case.  The first match wins, other candidates are bypassed.

 - CREATE EXTENSION ... WITH SYSID ...

   Thinking about upgrades, I added support for that too.  This might be
   necessary for pg_upgrade, but I'm not so sure.  It was an experiment
   but I though we might as well talk about it before I remove it from
   the patch :)

 - ALTER OBJECT ... SET EXTENSION ...

   This implements the magic behind "upgrading from null", as it allows
   the users to add objects to an existing extension.  Internally, this
   will only record a INTERNAL depedency between the object and the
   extension.

   This is mainly for use in upgrade scripts when you support pre-9.1
   extension upgrade, or for internal PL code that grows into an
   extension after the fact.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


Attachment

pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Extension support for pg_dump, patch v23
Next
From: Heikki Linnakangas
Date:
Subject: Re: regclass without error?