On Wed, Feb 2, 2011 at 12:31 PM, David E. Wheeler <da...@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, then I'd have 15 upgrade scripts. 
> That's fine. But in your plan, the script to upgrade from version 1 to 
> version 15 would have all the same code as the v14 script, plus any 
> additional. The v14 script would have everything in v13. v13 would have 
> everything in v12. With no support for the equivalent of psql's \i, that's 
> extremely redundant and a huge PITA to 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 from v1 to v15, UPGRADE 
> EXTENSION would run all of them. So v15 would only need to have deltas from 
> v14. V14 would need only deltas 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,
ai...@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to