Re: ALTER EXTENSION UPGRADE, v3

On Feb 11, 2011, at 10:58 AM, Aidan Van Dyk wrote:

> I release exetension "afoo", initial as version 1.0.  From my
> understanding, it's going to contain:
>    afoo control file, named something particular)
>      - default_version = 1.0
>      - encoding utf8
>    foo-1.0.sql installstion script
>    and any requried shared libraries
>
> And I now release and updated version 1.1 which fixes a problem.  No problem:
>   afoo control file:
>     - default_version = 1.1
>     - encoding utf8
>   afoo-1.1.sql installation
>   afoo-upgrade-1.0-1.1.sql upgrade script
>   any required shared libraries for afoo-1.

Oh. Would be nice if default_version assumed that an unversioned file was the default, actually. That way I don't have
torename the file in my repository every time I want to make a release. That will mess with my Git version history. 

> Now, I decide to add some major new changes to my afoo for version 2.
> I'ld like to package it up:
>   afoo control file
>    - default_version = 2.0
>    - encoding utf8
>   afoo-2.0.sql installation
>   afoo-upgrade-1.1-2.0-sql upgrade script
>   Any ne shared libreries for afoo-2.
>
> This gives my first problem.  I can't package afoo-2.x seperately from
> afoo-1.x, because they both want to write the afoo control file.
> RPM/DPKG will cause me grief here.

1.x would have its own control file. 1 control file per version (at most).

> But now, let's make it harder.  I've found a grave bug in 1.1, which
> causes the PG backend to segfault.  Easy fix, good thing, so now I
> release 1.2:
>  afoo control file
>    - default_version = 1.2
>    - encoding utf8
>  afoo-1.2.sql installation
>  afoo-upgrade-1.0-1.1.sql upgrade
>  afoo-upgrade-1.1-1.2.sql upgrade
>  any shared libraries for afoo-1
>
> So, this is not a problem for upgrading 1.0/1.1 -> 1.2.  But if I have
> 1.1 on my system, and let's say I forced a 2.0 into the system
> (telling dpkg/rpm to overwrite the common file), I'm going to do that
> again here now with 1.2, and my afoo control file will have
> default_version = 1.2 instead of the 2.0

Why wouldn't it have 2.1? You'd have added afoo-upgrade-1.1-1.2.sql and afoo-upgrade-2.0-2.2.sql.

> So, I'm not even working about the in-database side of the
> multi-versions (alhthough I definately want the ability to have
> multiple versions in the same database), but we're not even going to
> be able to get the files onto the system to support multiple versions
> nicely.

I'm not following why not.

> So this is going to drive me the same direction the same problem drove
> packages for rpm/dpkg.  I'm going to have to name my extension
> "afoo-1" and "afoo-2" to be able to have them both co-exist on the
> filesystem independantly, and at that point, *I* don't need multiple
> versions of it anymore.  I'm going to keep the same extension
> objects/libraries backwards compatible, and I just need a way to tell
> PG to run something after I've replaced the shared libraries to
> perform any  upgrade tweeks.

Oh, I think I see. You want to distribute 1.2 and 2.1 as separate downloads. I think the idea here is that you'd still
haveonly one distribution download, but it would contain both 1.2 and 2.1. Then you have no conflicts. 

Best,

David