[postgis-devel] [PostGIS] #1123: Create a legacy_compatibility_layer.sql.in.c

[PostGIS]

#1123: Create a legacy_compatibility_layer.sql.in.c
---------------------+------------------------------------------------------
 Reporter:  robe     |       Owner:  robe         
     Type:  defect   |      Status:  new          
 Priority:  high     |   Milestone:  PostGIS 2.0.0
Component:  postgis  |     Version:  trunk        
 Keywords:           |  
---------------------+------------------------------------------------------
Description changed by robe:

Old description:

> There are several functions commonly used by GUIs and web apps or even
> our old code.  Moving to PostGIS 2.0 will make it difficult for people to
> use these apps or even restore some of their tables unless they install
> the legacy.sql.
>
> Legacy.sql has a bit too much.  So my plan to conquer all worlds and
> minimize on redundancy is the following
>
> 1) remove these functions from legacy.sql.in.c: srid, ndims, AsText,
> AsBinary, extent are first that come to mind since not having some of
> these prevent tables helped by populate_geometry_columns from being
> restored.
>
> 2) The above listed will get moved to a new file called
> legacy_compatibility_layer.sql.in.c
>
> 3) Include this new file in legacy.sql.in.c
>
> So this will allow people to have a fairly clean slate but still be for
> the most part cross functional with old code.
>
> 4) add legacy_compatibility_layer.sql as a target build
>

> 4) Update the hard_upgrade instructions to be:
>
> build new database
> run legacy_compatibility_layer.sql
> restore old database
> run upgrade minor script
> run uninstall_legacy.sql (if they want to get rid of old junk, but let
> them know they can safely ignore errors since the uninstall will won't be
> able to uninstall things in use in views, sql functions, or table
> constraints)

New description:

 There are several functions commonly used by GUIs and web apps or even our
 old code.  Moving to PostGIS 2.0 will make it difficult for people to use
 these apps or even restore some of their tables unless they install the
 legacy.sql.

 Legacy.sql has a bit too much.  So my plan to conquer all worlds and
 minimize on redundancy is the following

 1) remove these functions from legacy.sql.in.c: srid, ndims, AsText,
 AsBinary, extent are first that come to mind since not having some of
 these prevent tables helped by populate_geometry_columns from being
 restored.

 2) The above listed will get moved to a new file called
 legacy_compatibility_layer.sql.in.c

 3) Include this new file in legacy.sql.in.c

 So this will allow people to have a fairly clean slate but still be for
 the most part cross functional with old code.

 4) add legacy_compatibility_layer.sql as a target build


 5) Update the hard_upgrade instructions to be:

 {{{

 build new database
 run legacy_compatibility_layer.sql
 restore old database
 run upgrade minor script
 run uninstall_legacy.sql (if they want to get rid of old junk, but let
 them know they can safely ignore errors since the uninstall will won't be
 able to uninstall things in use in views, sql functions, or table
 constraints)
 }}}

--

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1123#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.