Re: ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> 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.

Well, fair enough I suppose. Or it would be if you gave me an
alternative that provides a simpler way to support those 3 upgrades.

Of course if that's too much for you, you can also choose to only
support upgrades one versions at a time and provide only two scripts.
Note also that I don't recall of any proposal on the table that would
help with that situation, so I'm all ears.

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