[postgis-devel] postgis_upgrade.sql

[Paragon Corporation]

That could get unwieldy.

You would also need a 

Upgrade_1.3_to_1.5.sql.

I was thinking of the idea of a plpgsql function we preinstall that  the
user runs that checks the system catalogs and deletes all stuff
conditionally we can get away with deleting or we know changed (so no DROP
CASCADE since that's dangerous)

Then once they run -- they run the regular upgrade script.  I suspect a lot
of people have remnants from past installs that make the simple idea of
upgrade_x_y not full proof.

Thanks,
Regina

 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Cave-Ayland
Sent: Wednesday, June 24, 2009 4:24 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] postgis_upgrade.sql

Paul Ramsey wrote:

> Yes, it's known and it's filed here:
> http://trac.osgeo.org/postgis/ticket/202
> 
> My changes to make the script work properly going from 1.3 to 1.4 mean 
> that incremental changes from 1.4.x -> 1.4.y don't work. Solutions 
> welcome.
> 
> P

I'd like to suggest that now we are freezing API changes, how about we just
add new directory in SVN called upgrades/, and in there we place suitable
SQL files such as:

upgrade_1.3_to_1.4.sql
upgrade_1.4_to_1.5.sql

Then developers can simply add to the upgrade script themselves containing
the changes that are required. It means a little more work for developers,
but it will make the upgrade process a lot less painful going forward.


ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius
Corporation plc - control through freedom http://www.siriusit.co.uk
t: +44 870 608 0063
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel