Re: ALTER EXTENSION UPGRADE, v3
От | David E. Wheeler |
---|---|
Тема | Re: ALTER EXTENSION UPGRADE, v3 |
Дата | |
Msg-id | 81CD952A-799A-4851-9018-AB6BE6AFACAF@kineticode.com обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION UPGRADE, v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Feb 10, 2011, at 12:02 PM, Tom Lane wrote: > 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. Yes, exactly. > 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. And that was essentially my original proposal. > 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. I always thought it was. Best, David
В списке pgsql-hackers по дате отправления: