"David E. Wheeler" <david@kineticode.com> writes:
> 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.
That's easy enough to manage in your Makefile, really:
upgrade.null-v15.sql: upgrade.v14.sql upgrade.v15.sqlcat upgrade.v14.sql upgrade.v15.sql > $@
There's a difference between what you maintain and what you ship.
> 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.
What if you can reuse the later script for upgrading from any previous
version, like when the extension only contains CREATE OR REPLACE
statements (functions only extension, like adminpack).
I don't see benefits in your proposal.
> The number of upgrade script files is not the problem I have. It's the redundant content of those files that raises
myire.
>
> If there was some way to get something like \i in your approach, that would satisfy me, as it would be only an extra
line(at most) in each script. And then, as you note, the core wouldn't need the complexity of understanding version
numbers,which I agree would be beneficial.
It all comes down to the benefits. I don't see any in your proposal.
That might be just me though.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support