Create a legacy_compatibility_layer.sql.in.c

[robe]

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 on top of new 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)

[robe]

I've done the creation of this file in r7693 which contains ndims and srid functions needed to restore data from tables created using the old populate_geometry_columns.

I'm thinking that as part of the upgrade_minor script I should have a helper function that runs looking for tables built with the old named constraints and rebuild the containts using the new names so that when uninstall_legacy.sql is run, its less likely to error out.

[strk]

now that new_postgis_restore.pl converts those costraints, do we still need the compatibility layer ? In any case, can we close this ticket given we have the script already ?

[robe]

Yes we still do. Doesn't your script leave out functions dropped? There are a couple of functions in there for people who have old apps they can't change e.g it has commonly used funcs like AsText etc. So includes the most common.

I'll close this out though since its down.

[robe]

I was thinking we might be able to take out the srid and ndims from legacy compatibility but realize we can't take out srid since its used in old apps and might as well leave in ndims for those people that don't have perl on their server. Which I can almost guarantee most windows users don't since its blocked by many IT groups or if they do they have no clue how to use it.

Do you still think we need a prep script to handle updating srid and french srid to something in range or does your script handle that already? I guess for non-perl users we'd still need that though and restore you can't change geometries easily anyway so we'd proably still need it for the French.