Rename folders/files to be more consistent

[mcayland]

With the clear split between liblwgeom and the PostgreSQL-specific lwgeom/ directory, it would make sense to rename the lwgeom/ directory to postgis/.

Similarly I'd like to suggest renaming the following files:

lwpostgis.sql → postgis.sql liblwpostgis → libpostgis-1.4

I think this will make things much clearer. Also by adding in the version number into the PostgreSQL shared library, it means moving ahead that developers/users can easily have multiple versions installed which I see as being very useful in the time ahead.

[robe]

I'm okay with renaming to postgis.sql and even renaming the foler. Would it be too much to ask to move the postgis.sql file back to the root where the spatial_ref_sys.sql is. It is too much of a brain cramp for me to look for it elsewhere

[pramsey]

Re-naming commonly known things (this name has been around for a while now) is generally bad, but since we've already *moved* the file, we might as well re-name it too. I wish we could put a number on it without breaking other things… postgis-14.sql. But then we'd have to number our so/dlls and then upgrades would get even tricker, and then…

[mcayland]

Regina: this also brings in the issue that since PROJ.4 is compulsary for SVN trunk, should we automatically #include spatial_ref_sys into postgis.sql?

Paul: I don't have a problem with renaming files on a minor version bump. Anything that changes a minor release screams 'there have been some changes here, please test first before deployment'. So as long as we document this, I don't see this being a problem.

Also, I'd still like to propose version numbering the so/DLL - this will make testing/installing multiple versions so much easier. I don't see upgrades being a problem, since you don't need to know the name of so/DLL containing a function to be able to drop it, and the upgrade script for version X already knows the name of its own so/DLL. I'm sure we can also devise something that will flag big warnings/errors if mixed so/DLL versions are present in the system catalogs.

ATB,

Mark.

[robe]

Mark,

The answer to your question about spatial_ref_sys.sql is NO.

The reason I feel that way is if I'm doing a hard dump reload — I have a lot of custom records in my spatial_ref_sys and I may not care to load the ones you have or I may want a partial set to save space. This is not true with the functions. I always want all of those . Call me selfish —-.

I'm all for going hog wild on stamping 1.4. 1.4 will be a big change and it would be really nice if I can run both simultaneously on the same PostgreSQL service and then slowly port over at my leisure.

[mcayland]

Okay, I've just committed the rename of lwpostgis.sql to postgis.sql, and the embedding of the version number in the resulting .so/DLL file. It seems to work for me, but let me know if I accidentally broken anything.

Next, I'll come along and rename the lwgeom/ directory to postgis.

ATB,

Mark.

[pramsey]

I can do the ./lwgeom/ rename if you wish, Mark.

P

[mcayland]

Hi Paul,

If you could, that would be quite helpful. I did a version of this ready to commit, but I wasn't 100% convinced that the version history would be preserved (I think I got this wrong on the liblwgeom breakout). Feel free to experiment with 'svn rename' versus 'svn copy/svn delete' to see which one actually works

ATB,

Mark.

[pramsey]

Done. Note that if you're using TortoiseSVN, you'll need to uncheck 'Stop on copy/rename' in the log display options, or the revisions will appear to have been lost.

[pramsey]

<i>(No comment was entered for this change.)</i>