[postgis-devel] New uninstall_postgis.sql script

[Paragon Corporation]

Tom,
I suppose touching the system tables is a big no no too or not possible (I
think its just the .so, .dll file that changed in our case)

 (or is that what you were thinking with the PgMigrator as part of the
catalog table changes it does).  I think our main issue is just with types
and possibly aggregates (if people have views against aggregates).

I've been doing dumping reloading so haven't fully tested.  So its just the
annoying fact that TYPE has no CREATE OR REPLACE like functions do.  If such
a thing existed for TYPES I would expect all of this would be a non-issue.

As far as people going from PostgreSQL 8.3 + Postgis 1.3  ->  PostgreSQL 8.4
+ PostGIS 1.3  

I haven't tried it yet but being at the Bruce's talk -- I think his approach
will work fine for those folks since non of the types, lib names, signatures
etc. changed.

Of course there is the lame solution that we simply don't change our .so,
.dll names then 1.3 to 1.4 migration would be the same as any other
migrations in the past (except for the drop aggregate addition) and DROP IF
EXISTS for the new pg_abs types.

Thanks,
Regina

 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Tom Lane
Sent: Saturday, June 06, 2009 1:31 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] New uninstall_postgis.sql script

"Obe, Regina" <robe.dnd at cityofboston.gov> writes:
> At the moment, the script simply uses DROP TYPE ... CASCADE on the 
> PostGIS types which removes them completely from the database; however 
> it struck me that this could be a way of unifying our 
> installation/removal/upgrade procedures since an upgrade process 
> involves removing all of the old definitions and adding the new ones.
> Obviously this would only work with 1.4 onwards, but easier upgrades 
> would put us in a great position going forwards. Thoughts?

You might want to have a look at the recent discussions about pg_migrator on
the pgsql-hackers list.  We are currently wondering about how to do
upgrade-in-place in the presence of add-on modules, and it looks like a mess
if the add-on modules' SQL-level definition has changed at all.  In
particular, DROP TYPE ... CASCADE is really a complete nonstarter for
upgrades, because it will happily remove all the user's data columns of that
type!

My own thoughts are running to the idea that the add-on module would need to
provide a version update script that drops and re-adds only the SQL
definitions that actually changed.  Obviously this is a PITA from a
maintenance standpoint, but I'm not seeing any other workable answer.

If you missed the upgrade discussion at PGCon, it's worth looking at the
slides and/or video:
http://www.pgcon.org/2009/schedule/events/189.en.html

			regards, tom lane
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel