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

From David Christensen
Subject Re: ALTER EXTENSION UPGRADE, v3
Date
Msg-id 1BF06196-2A22-434D-92F9-0C649674B8F5@endpoint.com
Whole thread Raw
In response to Re: ALTER EXTENSION UPGRADE, v3  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
>> 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. 


I assume this has already been discussed and rejected (or it wouldn't still be an issue), but what's wrong with the
equivalentof \i in the successive .sql upgrade files?  Or is the server running the scripts itself and no equivalent
includefeature exists in raw sql? 

Regards,

David
--
David Christensen
End Point Corporation
david@endpoint.com






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SPI_exec doesn't return proc context (on 9.1)
Next
From: Daniel Farina
Date:
Subject: Re: Debian readline/libedit breakage