On Wed, Feb 2, 2011 at 12:31 PM, David E. Wheeler <david@kineticode.com> wrote:
>
> They are identical except for the extra line in the second one. If I had, say 15 different versions of an extension,
thenI'd have 15 upgrade scripts. That's fine. But in your plan, the script to upgrade from version 1 to version 15
wouldhave all the same code as the v14 script, plus any additional. The v14 script would have everything in v13. v13
wouldhave everything in v12. With no support for the equivalent of psql's \i, that's extremely redundant and a huge
PITAto maintain. Hence my hate.
>
> My proposal would also have 15 upgrade scripts, but each one would only upgrade from the previous one. So to upgrade
fromv1 to v15, UPGRADE EXTENSION would run all of them. So v15 would only need to have deltas from v14. V14 would need
onlydeltas from v13. Etc.
My concern with this approach (upgrade is forced through all
intermetiary versions) is that the shared libray now for version 15
*has* to have all the "intermediary" compatibility for *all* versions
in it. So it has to have functions with all symbols so the "CREATE
..." staements for all previous 15 versions can succeed.
With having the $old -> $new scripts, the new .so only needs to have
functions enough that the DROPs work, and the new CREATE... work.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.