[postgis-devel] postgis_upgrade.sql

[Kevin Neufeld]

I kinda agree.  Wouldn't we have to have an upgrade script for every permutation.

What if instead of a one large plpgsql script, we were to wrap all the function/casts/type/etc declarations in their own 
plpgsql script that does a simple test and upgrades the function/type if needed.
ie.

CREATE OR REPLACE FUNCTION upgrade_function() RETURNS text AS
$$
DECLARE
   postgisVersion text;
BEGIN
   postgisVersion := postgis_version();
   IF (postgisVersion < '1.3') THEN
     EXECUTE 'DROP FUNCTION deprecated_postgis_function';
   END IF;
   EXECUTE 'CREATE OR REPLACE ST_Box(box3d) ...';
   RETURN 'done';
END
$$ LANGUAGE plpgsql;
SELECT upgrade_function();
DROP FUNCTION upgrade_function();

I don't know, this seems quite unwieldy too.
-- Kevin


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