Re: Upgrading Extension, version numbers - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: Upgrading Extension, version numbers
Date
Msg-id 4F6DA017-3230-46C0-9887-B223E6F8E92C@kineticode.com
Whole thread Raw
In response to Re: Upgrading Extension, version numbers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Jan 4, 2011, at 12:05 PM, Dimitri Fontaine wrote:

> "David E. Wheeler" <david@kineticode.com> writes:
>> * Prefer convention over configuration
>
> The previous idea about the convention is not flying well with the very
> recent proposal of ALTER EXTENSION ... UPGRADE TO VERSION ..., because
> it would certainly require that the extension's name include its major
> version number, like debian is doing for a number of packages.

No, just the file.

> Also, how are PostGIS 1.4 and 1.5 (and 2.0) packaged nowadays?

Tarballs.

>> * Not make me do more work that the computer can do
>
> No computer will guess reliably which upgrade file to apply given the
> currently installed version and the newer one, as soon as the same file
> can get used for more than a single combination of those two strings.

Why not? Version numbers would have to be part of the file names. The only wrinkle is being able to properly order
versionnumbers, and we could address that by requiring a specific version format. Tom suggested integers; I suggested
semanticversions. 

> I much prefer to avoid shipping that many files, and thinks that even in
> the worst case where you have to add a setup line per supported upgrade
> setup, the control file support for that is better.

Well, for a version that requires no upgrade script, there just wouldn't be one.

It's a matter of taste.

> Now I perfectly understand that there's more to this world than my eyes
> can see, that's why we're talking about alternatives.

You are?

Best,

David




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Tracking latest timeline in standby mode
Next
From: Tom Lane
Date:
Subject: Fixing GIN for empty/null/full-scan cases