On Feb 2, 2011, at 10:04 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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.sql
> cat upgrade.v14.sql upgrade.v15.sql > $@
Sure, if you know Make really well. But then I need to add a line to the Makefile for every bloody upgrade script. Gross.
> 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 understand the question.
> I don't see benefits in your proposal.
The benefit is reduced redundancy.
> It all comes down to the benefits. I don't see any in your proposal.
> That might be just me though.
In response to
pgsql-hackers by date
|Next:||From: Mladen Gogala||Date: 2011-02-02 18:11:33|
|Subject: Re: [HACKERS] Slow count(*) again...|
|Previous:||From: Dimitri Fontaine||Date: 2011-02-02 18:04:26|
|Subject: Re: ALTER EXTENSION UPGRADE, v3|