Re: ALTER EXTENSION UPGRADE, v3 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: ALTER EXTENSION UPGRADE, v3
Date
Msg-id 1297951163.31633.4.camel@fsopti579.F-Secure.com
Whole thread Raw
In response to Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote:
> > 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.

I think this shows that the installation script version number should be
independent of the overall package's version number.  You just change
the installation script version number when it is required that the
script be run as part of an upgrade, otherwise you leave it.  This is
very similar to the version numbers of shared libraries, which also
change independently of the overall package.

So perhaps installation script version numbers should just be integers
starting at 1, period.

Otherwise I fear people will try to make the numbers match their package
version number, which will either create stupid installation script
sequences or stupid package version numbers, like those peculiar fellows
who change the shared library version number in accordance with their
package version number.

This would of course also simplify many other aspects about which
version numbers to allow and how to compare them.




pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Fix for Index Advisor related hooks
Next
From: Peter Eisentraut
Date:
Subject: Re: why two dashes in extension load files