From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER EXTENSION UPGRADE, v3 |
Date: | 2011-02-11 19:35:53 |
Message-ID: | AANLkTinn4dA9OymdakjAba1zN8rH8KC0=wbdGw=9Bgj9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
>
> No, you ship *one* package that supports both 1.1 and 2.0.
Hm... As an example of a project that generally has pretty good
software release practices, I'm glat that the PostgreSQL project
doesn't operate this way.
Having to download/install/upgrade a package with all of pg
9.1.$lateset and 9.0.$latest just to get a fix for 8.4.$latest would
be a bit of a bummer...
And a hopefull extension author/packages/user, I *want* to be able to
release/distribute different versions seperately, just like PostgreSQL
does. And I'll do that by packaging my extension with a "major"
version in the name, much like the packages for PostgreSQL does. But
once I've done that, I don't need the multiple extension versions, all
I need is the ability to run $something when I upgrade an extension,
once the files under it have been upgraded.
;-)
>> 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:
>
> Unless the bug is such that you have to change the installation script
> file, there is no reason to bump the version number at all. These
> version numbers apply to the install SQL script, not the underlying .so.
Right. If everything is exactly binary compatible and it's just a .so
fix, I don't need to. But let's assume something like slonly (or
bucardo or longdiste, or PyQ, or PostGIS) start's trying to make use
of extensions. I can very much see a "bug fix" minor version upgrade
changing things that might need trigers/etc to be altered to take
advantage of the fixed way of doing things. Or a SQL view/function
had a bug with an null handling joins that needs fixing, etc. Lots
of reasons for an "upgrade" to need to change an SQL object.
And of course, if I have slony 1.2.$x replicating one of my databases,
I'ld love to be able to try slony 2 and have it packaged on my system
too to test somethign else. And not have to upgrade my slony 2
instance just to get the critical bugfix for my production slony
1.2$x+1.
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-02-11 19:44:13 | Re: Range Types: empty ranges |
Previous Message | Robert Haas | 2011-02-11 19:21:25 | Re: Debian readline/libedit breakage |