[postgis-devel] Upgrades

[Paul Ramsey]

I have spend several hours thinking about this stuff, reviewing my old
world and Regina's code in here
(http://trac.osgeo.org/postgis/attachment/ticket/202), and I've
decided I hate it all.

The old way, generating a postgis_upgrade.sql file from the
postgis.sql file is a beauty, I love it, but it conditional stuff gets
really ugly and since 1.3 we've added conditional stuff: the upgrade
to 1.4 required two new types, which you would want defined for 1.3 ->
1.4.0 but ignored for 1.4.0 -> 1.4.1.

And the upgrade to 1.5 just piles onto that a couple new types a pile
of operators and a couple operator classes, all of which would require
conditional handling to add them for upgrades from previous major
versions but ignore them for upgrades from minor versions.

And this got me thinking about upgrades in general, and how our
current "best" upgrade advice is not actually any fancy script process
but simply:

- create a new database with the new version of postgis in it
- dump from the old database and restore into the new one
- ignore the errors

Works pretty good. And all that conditional mess in the upgrade
scripts could similarly be dropped if the upgrade process was

- run the upgrade script
- ignore the errors

So. Here I am. Mark, I know, favors some kind of fragment approach,
and I thought about that a good while too but never came up with a
scheme that wasn't going to be very very hard to maintain. (It took me
half-an-hour just to remember the issues involved in upgrade. If I
needed to keep the issues in mind every time I altered a function
definition in the SQL files, that could be a bit much.)

So my current suggestion is "worse is better". Move to an "ignore the
errors" upgrade policy and fully document that.

P.