Re: ALTER EXTENSION UPGRADE, v3 - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: ALTER EXTENSION UPGRADE, v3
Date
Msg-id AANLkTimv_xkpzh-qsbzLqFSYV-j_d2FUM7wUN-s=iJ_5@mail.gmail.com
Whole thread Raw
In response to Re: ALTER EXTENSION UPGRADE, v3  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: ALTER EXTENSION UPGRADE, v3  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Wed, Feb 2, 2011 at 20:29, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> I didn't think about "detach", I'm not sure I see the use case…

The latest extension might drop some functions.

> It's not about upgrading major versions, it's about upgrading
> extensions.  The only time you will need to run the scripts in the patch
> is e.g. when upgrading the extension hstore from NULL to 1.0.  Once
> done, hstore is registered as an extension, you're done.  No need to
> redo that or maintain the upgrade script for 9.1 to 9.2.

I'm still not clear what "upgrade" means. if module authors wrote
functions with C, they can just replace .so to upgrade. If with
SQL or PL/pgSQL, they should execute CREATE OR REPLACE FUNCTION.

The patch seems useful to upgrade from NULL to 1.0, but I cannot
imagine how it work for cases from 1.0 to higher versions.
For example, if we have 3 versions of a module below: NULL  unmanaged functions only v1    EXTENSION support with an
additionalfunction v2    EXTENSION support with another function. 
How do we write upgrading scripts for NULL=>v1, NULL=>v2, and v1=>v2 ?

--
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: SSI patch version 14
Next
From: Markus Wanner
Date:
Subject: Re: SSI patch version 14