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

From Tom Lane
Subject Re: ALTER EXTENSION UPGRADE, v3
Date
Msg-id 7613.1297374589@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER EXTENSION UPGRADE, v3  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> "David E. Wheeler" <david@kineticode.com> writes:
>> Yes, I think that this is a great solution. I only have to create on
>> upgrade script for each release, and I don't have to worry about
>> concatenating anything or be required to change my versioning
>> algorithm.

> You still have to make sure that the C code remains compatible with any
> intermediate release, for the whole life of your extension.  But I agree
> that it's way better than what we had before.

What you have to do is make sure the C code remains compatible with any
version you are shipping an install or upgrade script for.  Once you
decide that versions before, say, 2.0 are dead as doornails, you remove
all the older scripts, and you can delete the .so infrastructure for
them too.

For example, suppose I have foobar 1.5 installed on my system.  If you
are shipping a package that includes foobar-1.5-2.0.sql, I should
reasonably expect that I can install that package first and upgrade the
extension afterwards.  If you aren't shipping any script that claims it
can upgrade from 1.5, you don't need to provide .so compatibility either
--- it's clear that I have to upgrade first and install your newer
package after.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: ALTER EXTENSION UPGRADE, v3
Next
From: David Fetter
Date:
Subject: Re: [COMMITTERS] pgsql: Remove more SGML tabs.