[postgis-devel] Upgrades

[Paul Ramsey]

Well, in that case I am going to proceed with what I consider the
least painful approach and build 4 upgrade scripts

postgis_upgrade_1.5_minor.sql
postgis_upgrade_1.4_to_1.5.sql
postgis_upgrade_1.3_to_1.5.sql
postgis_upgrade_1.2_to_1.5.sql

I'll also be adding a postgis_removed.sql.in.c file that includes old
functions that are no longer available in 1.5 and can be DROP FUNCTION
IF EXISTS.

P.

PS - In case you missed a commit from this morning, I put back in the
st_ functions that back operators and types, since those are not
in-place updatable.

On Thu, Nov 12, 2009 at 1:15 PM, Paragon Corporation <lr at pcorp.us> wrote:
> Paul,
> hmm -- I don't like that policy because it results in broken installs.
> There are some errors you can't ignore and shouldn't.
>
> Even more so now than before.  As I said -- with the lets ignore the errors,
> you'll have people with bits of there PostGIS 1.5 pointing at bits of 1.4
> and 1.3.  Not good.  Keep in mind all these will sort of work since we can
> now have multiple PostGIS versions running on a PostgreSQL server instance.
>
> I also don't always like the dump restore especially for large databases,
> and that's really the only case where you can safely ignore the errors.
>
> I have for example a client that has a 800 GB database.  There is no way I'm
> going to sell them on a dump restore - especially since they just moved into
> their new brank spanking server.  Yes I can work around it and remove the
> remnants and stuff, but most people can not.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Thursday, November 12, 2009 3:29 PM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Upgrades
>
> 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.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>