Re: ALTER EXTENSION UPGRADE, v3

Поиск
Список
Период
Сортировка
От David Christensen
Тема Re: ALTER EXTENSION UPGRADE, v3
Дата
Msg-id 1BF06196-2A22-434D-92F9-0C649674B8F5@endpoint.com
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION UPGRADE, v3  ("David E. Wheeler" <david@kineticode.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SPI_exec doesn't return proc context (on 9.1)
Следующее
От: Daniel Farina
Дата:
Сообщение: Re: Debian readline/libedit breakage