Re: ALTER EXTENSION UPGRADE, v3

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.