On Feb 2, 2011, at 9:19 AM, Dimitri Fontaine wrote: > I see there no solution to your reaction here. Please take the time to > tell us more about what exactly it is that you hated, and how to make it > lovely. We won't make any progress with your current commenting style.
Here is your example of the two upgrade scripts: > Now, the upgrade script from version NULL to 1.0 is > > alter domain @extschema@.lo set extension lo; > alter function @extschema@.lo_oid(lo) set extension lo; > alter function @extschema@.lo_manage() set extension lo; > > The upgrade script from version 1.0 to 2.0 is, let's say: > > CREATE OR REPLACE FUNCTION @extschema@.lo_newfunc() … > > So the upgrade script from version NULL to 2.0 is: > > alter domain @extschema@.lo set extension lo; > alter function @extschema@.lo_oid(lo) set extension lo; > alter function @extschema@.lo_manage() set extension lo; > CREATE OR REPLACE FUNCTION @extschema@.lo_newfunc() … 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. The number of upgrade script files is not the problem I have. It's the redundant content of those files that raises my ire. 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. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
