Re: ALTER EXTENSION UPGRADE, v3

On Fri, Feb 11, 2011 at 6:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> No --- in the current vision, a control file may describe a whole
> collection of versions of the same extension, and the parameter in
> question is selecting the default or preferred version to install.
> I'm not wedded to "default_version", but I think just plain "version"
> is a misnomer.

As someone who wants to use extensions and packages (rpm/dpkg)
together to distribute PG database pieces, I think this multi-version
approach is going to be problematic.

Here's why.

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
librariesfor afoo-1. 


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-sqlupgrade 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.

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.sqlupgrade 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

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.

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.

a.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.