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

On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
>> On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
>>> I don't see how that affects my point?  You can spell "1.0" as "0.1"
>>> and "1.1" as "0.2" if you like that kind of numbering, but I don't
>>> see that that has any real impact.  At the end of the day an author is
>>> going to crank out a series of releases, and if he cares about people
>>> using those releases for production, he's going to have to provide at
>>> least a upgrade script to move an existing database from release N to
>>> release N+1.
>
>> Yeah, but given a rapidly-developing extension, that could create a lot of extra work. I don't know that there's
muchof a way around that, other than concatenating files to build migration scripts from parts (perhaps via `Make` as
dimsuggested). But it can get complicated pretty fast. My desire here is to keep the barrier to creating PostgreSQL
extensionsas low as is reasonably possible. 
>
> Oh, I see, you're just saying that it's not unlikely somebody could find
> himself with dozens of minor releases all being supported.  Yeah, he'd
> then really need to provide shortcut upgrade scripts, and
> building/maintaining those would be a pain.
>
> The design as I sketched it didn't need to make any assumptions at all
> about the meaning of the version identifiers.  But if you were willing
> to assume that the identifiers are comparable/sortable by some rule,
> then it wouldn't be that hard for ALTER EXTENSION UPGRADE to figure out
> how to chain a series of upgrade scripts together to get from A to B,
> and then there would be no need for manual maintenance of shortcut
> scripts.  IIRC the main objection to doing it that way was that the
> underlying .so has to be compatible (at least to the extent of allowing
> CREATE OR REPLACE FUNCTION) with all the intermediate versions --- but
> if you believe the use-case I'm arguing for, that would be wanted
> anyway, because all the intermediate versions would be considered
> potentially useful stopping points.
>
> I'm not philosophically opposed to requiring the version numbers to be
> sortable, I just didn't want to introduce the concept if we didn't have
> to.  But maybe automatic application of a series of upgrade scripts is
> enough reason.

You don't need them to be sortable.  You just need them to be
comparable, and equality seems like a plenty good enough comparison
rule.  You can compute the shortest chain of upgrade scripts that can
take you from the current version to the target version.

But I'd be happy to leave that for 9.2.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company