From: Sandro Santilli Date: Mon, 13 Feb 2012 18:06:53 +0000 (+0000) Subject: Allow retaining all custom spatial_ref_sys entries, even clashing X-Git-Tag: 2.0.0alpha5~23 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8b316be887bf6d27a7e837da388e747ae520e2e5;p=postgis Allow retaining all custom spatial_ref_sys entries, even clashing Update manual accordingly (hard upgrade procedure) git-svn-id: http://svn.osgeo.org/postgis/trunk@9175 b70326c6-7e19-0410-871a-916f4a2858ee --- diff --git a/doc/installation.xml b/doc/installation.xml index 589248a19..814deeff9 100644 --- a/doc/installation.xml +++ b/doc/installation.xml @@ -1199,38 +1199,30 @@ pretty_address - - Some of the tables in your dump may be using an - out-of-range SRID value. SRID range goes from 0 to 999999. - In this case both your geometries and relative entries in - spatial_ref_sys will be converted to a SRID in the - reserved range 999000..999999. Different source SRIDS may - end up mapping to the same target SRID in which case - all your spatial_ref_sys entries will fail to restore. - The postgis_restore.pl script will let you know about - all these conversions with WARNING messages on the standard - error stream. - Note that even successful conversion will need to be - post-processed to get data out of the reserved SRID range. - See next paragraph about that. - You may prevent all this noise by ensuring the SRID - of your tables is within the valid range _before_ dumping. - - - Some custom records of spatial_ref_sys in dump file have an invalid SRID value. Valid SRID values are bigger than 0 - and smaller than 999000. In this case your custom records - will be retained but the spatial_ref_sys table would loose - a check contraint guarding for that invariant to hold. + and smaller than 999000. Values in the 999000.999999 range + are reserved for internal use while values > 999999 can't + be used at all. + All your custom records with invalid SRIDs will be retained, + with those > 999999 moved into the reserved range, but the + spatial_ref_sys table would loose a check contraint guarding + for that invariant to hold and possibly also its primary key + ( when multiple invalid SRIDS get converted to the same reserved + SRID value ). + + + In order to fix this you should copy your custom SRS to a SRID with a valid value (maybe in the 910000..910999 range), convert all your tables to the new srid (see ), delete the invalid - entry from spatial_ref_sys and re-construct the check with: + entry from spatial_ref_sys and re-construct the check(s) with: ALTER TABLE spatial_ref_sys ADD CONSTRAINT spatial_ref_sys_srid_check check (srid > 0 AND srid < 999000 ); + + ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid)); diff --git a/utils/postgis_restore.pl.in b/utils/postgis_restore.pl.in index 5e601b28f..4b033304d 100755 --- a/utils/postgis_restore.pl.in +++ b/utils/postgis_restore.pl.in @@ -131,6 +131,10 @@ if ( $hasTopology ) { # Drop the spatial_ref_sys_srid_check to allow for custom invalid SRIDs in the dump print STDOUT "ALTER TABLE spatial_ref_sys DROP constraint " . "spatial_ref_sys_srid_check;\n"; +# Drop the spatial_ref_sys primary key to allow for SRID conversions +# which possibly end up taking the same spot +print STDOUT "ALTER TABLE spatial_ref_sys DROP constraint " + . "spatial_ref_sys_pkey;\n"; # Backup entries found in new spatial_ref_sys for later updating the print STDOUT "CREATE TEMP TABLE _pgis_restore_spatial_ref_sys AS " @@ -280,6 +284,10 @@ print STDOUT "DROP TABLE _pgis_restore_spatial_ref_sys;\n"; print STDOUT "ALTER TABLE spatial_ref_sys ADD constraint " . "spatial_ref_sys_srid_check check " . "( srid > 0 and srid < " . ($SRID_USER_MAXIMUM+1) ." ) ;\n"; +# Try re-enforcing spatial_ref_sys primary key, would fail if impossible +# but you'd still have your data +print STDOUT "ALTER TABLE spatial_ref_sys ENABLE TRIGGER ALL;\n"; +print STDOUT "ALTER TABLE spatial_ref_sys ADD PRIMARY KEY(srid);\n"; print STDERR "Done.\n";