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 по дате отправления: