On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:

> Well, you write 3 scripts.
> 
> Let's consider an example, the lo contrib, with its 3 objects:
> 
>  CREATE DOMAIN lo AS pg_catalog.oid;
>  CREATE OR REPLACE FUNCTION lo_oid(lo) …
>  CREATE OR REPLACE FUNCTION lo_manage() …
> 
> Now, the upgrade script from version NULL to 1.0 is
> 
>  alter domain @extschema(at)(dot)lo set extension lo;
>  alter function @extschema(at)(dot)lo_oid(lo) set extension lo;
>  alter function @extschema(at)(dot)lo_manage() set extension lo;
> 
> The upgrade script from version 1.0 to 2.0 is, let's say:
> 
>  CREATE OR REPLACE FUNCTION @extschema(at)(dot)lo_newfunc() …
> 
> So the upgrade script from version NULL to 2.0 is:
> 
>  alter domain @extschema(at)(dot)lo set extension lo;
>  alter function @extschema(at)(dot)lo_oid(lo) set extension lo;
>  alter function @extschema(at)(dot)lo_manage() set extension lo;
>  CREATE OR REPLACE FUNCTION @extschema(at)(dot)lo_newfunc() …
> 
> If as an extension author you're kind enough to provide all those 3
> scripts and the upgrade setup in the control file, then the user can
> issue ALTER EXTENSION lo UPGRADE; and have all your cases covered
> automatically.

As an extension author, I can't emphasize enough how much I hate the redundancy of this approach.

Best,

David

In response to

• Re: ALTER EXTENSION UPGRADE, v3 at 2011-02-02 14:45:45 from Dimitri Fontaine

Responses

• Re: ALTER EXTENSION UPGRADE, v3 at 2011-02-02 17:03:07 from Dimitri Fontaine

pgsql-hackers by date

Next:	From: Magnus Hagander	Date: 2011-02-02 17:00:42
	Subject: Re: Move WAL warning
Previous:	From: Tim Bunce	Date: 2011-02-02 16:45:52
	Subject: Re: Optimize PL/Perl function argument passing [PATCH]