From 926ca62b9f22573db6cec6c919d253dd3bb2a7a8 Mon Sep 17 00:00:00 2001 From: Sandro Santilli Date: Wed, 11 Jan 2012 08:26:36 +0000 Subject: [PATCH] Update HARD UPGRADE section, mention --with-topology git-svn-id: http://svn.osgeo.org/postgis/trunk@8760 b70326c6-7e19-0410-871a-916f4a2858ee --- README.postgis | 61 +++++++++++++++++++++++--------------------------- 1 file changed, 28 insertions(+), 33 deletions(-) diff --git a/README.postgis b/README.postgis index d16d6e2e3..504d37501 100644 --- a/README.postgis +++ b/README.postgis @@ -95,6 +95,9 @@ option. If you want to compile PostGIS with Raster support, you must provide the --with-raster option. +If you want to compile PostGIS with Topology support, you must provide +the --with-topology option. + See ./configure --help for more options. BUILD @@ -213,40 +216,32 @@ PostgreSQL database itself has undergone a major update. For this purpose, PostGIS provides a utility script to restore a dump in "custom" format. The hard upgrade procedure is as follows: - # Create a "custom-format" dump of the database you want + # [1] Create a "custom-format" dump of the database you want # to upgrade (let's call it "olddb") - $ pg_dump -Fc olddb olddb.dump - - # Restore the dump while upgrading postgis into - # a new database. - # Note: The new database does NOT have to exist. - # Let's call it "newdb" - $ sh utils/postgis_restore.pl postgis.sql newdb olddb.dump > restore.log - - # Check that all restored dump objects really had to be - # restored from dump and do not conflict with the - # ones defined in postgis.sql - $ grep ^KEEPING restore.log | less - - # If upgrading from PostgreSQL < 8.0 to >= 8.0 you will want to - # drop the attrelid, varattnum and stats columns in the geometry_columns - # table, which are no-more needed. Keeping them won't hurt. - # !!! DROPPING THEM WHEN REALLY NEEDED WILL DO HARM !!!! - $ psql newdb -c "ALTER TABLE geometry_columns DROP attrelid" - $ psql newdb -c "ALTER TABLE geometry_columns DROP varattnum" - $ psql newdb -c "ALTER TABLE geometry_columns DROP stats" - - # The spatial_ref_sys table is restored from the dump, to - # ensure your custom additions are kept, but the distributed - # one might contain modification so you should backup your - # entries, drop the table and source the new one. - # If you did make additions we assume you know how to backup them before - # upgrading the table. Replace it with the new like this: - $ psql newdb - newdb=> DELETE FROM spatial_ref_sys; - DROP - newdb=> \i spatial_ref_sys.sql - + $ pg_dump -Fc -f olddb.dump olddb + + # [2] Do a fresh install of PostGIS in a new database + # (let's call it "newdb"). + # Refer to CREATING NEW SPATIAL DATABASES for instructions + + # [3] Restore the dump into your new database. + $ perl utils/postgis_restore.pl -v olddb.dump \ + 2> restore.log | psql newdb 2> errors.txt + +The spatial_ref_sys entries found in your dump will be restored, but +they will not override existing ones in spatial_ref_sys. This is to +ensure that fixes in the official set will be properly propagated to +restored databases. If for any reason you really want your own overrides +of standard entries just don't load the spatial_ref_sys.sql file when +creating the new db. + +If your database is really old or you know you've been using long +deprecated functions in your views and functions, you might need +to load legacy.sql before restoring the dump +for all your functions and views etc. to properly come back. Only do +this if _really_ needed. Consider upgrading your views and functions +before dumping instead, if possible. The deprecated functions can be +later removed by loading uninstall_legacy.sql. USAGE ----- -- 2.40.0