[postgis-devel] Upgrades

[Paragon Corporation]

Okay good.  Those were the ones I was really concerned about. 

-----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 4:40 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Upgrades

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
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel