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 to rename 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 have only one distribution download, but it would contain both 1.2 and 2.1. Then you have no conflicts.

Best,

David