Re: ALTER EXTENSION UPGRADE, v3

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-02 13:12:51
Message-ID: AANLkTimv_xkpzh-qsbzLqFSYV-j_d2FUM7wUN-s=iJ_5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 2, 2011 at 20:29, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)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 additional function
v2 EXTENSION support with another function.
How do we write upgrading scripts for NULL=>v1, NULL=>v2, and v1=>v2 ?

--
Itagaki Takahiro

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Singer 2011-02-02 13:16:21 Re: pl/python explicit subtransactions
Previous Message Heikki Linnakangas 2011-02-02 13:04:28 Re: SSI patch version 14