"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 much
ofa way around that, other than concatenating files to build migration scripts from parts (perhaps via `Make` as dim
suggested).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.
regards, tom lane