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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
