[postgis-devel] Re: PostGIS datastore creation

[Paul Ramsey]

We appear to have slowed down on this discussion, so to pick up the 
thread, in public this time:

- The PostGIS FDO datastore has an interesting requirement. From a 
client-side, it needs the ability to create a new spatially-enabled 
database.
- This is not so wierd. It is possible to create a new ordinary database 
just using the "CREATE DATABASE" command, assuming you have sufficient 
privilege.
- But to create a spatially enabled database, you have to also source 
some SQL files on the server machine, and that is not something you can 
do without logging into the machine itself. So as a pure database 
client, it is NOT POSSIBLE.
- The workaround to this would be to have a standard spatially-enabled 
TEMPLATE available in the server install, a "template_gis", if you will.
- If we made this template part of our standard install process on 
Windows, and added a "make install_template" directive in our UNIX 
build, I think we could begin a migration to ensuring that this 
capability was generally available by the time the PostGIS FDO provider 
was in wide use.
- This would also be useful for any other client framework.  In fact, 
the Debian packaging already has this concept hanging around somewhere.

Thoughts?

Paul

Mateusz Loskot wrote:
> Paul Ramsey wrote:
>> First, here's an entry from the lwpostgis.sql file on my machine (OS/X).
>>
>> CREATE OR REPLACE FUNCTION shift_longitude(geometry)
>>         RETURNS geometry
>>         AS '$libdir/liblwgeom.1.1.so', 'LWGEOM_longitude_shift'
>>         LANGUAGE 'C' IMMUTABLE STRICT;
>>
>> Note the reference to liblwgeom.1.1.so. That's the PostGIS C library,
>> where all the smarts reside.  It's a .so,  because this is unix.  If
>> this was Windows, it would be a DLL.
> 
> Paul,
> 
> Now it's clear for me what you meant in previous e-mail
> regarding .so/.DLL differences. Thanks.
> 
>> To make things more confusing, some of the aspects of type-definition
>> and/or  index bindings are subtly different from version to version of
>> PostgreSQL.  So the lwpostgis.sql file for PostGIS 1.1.3 compiled for
>> PostgreSQL 7.4 is subtly different from the lwpostgis.sql for PostGIS
>> 1.1.3 compiled for PostgreSQL 8.1.
>>
>> Generally the client is insulated from server-side issues, and such
>> issues never crop up.
> 
> Yes, I see the source of our problems here.
> 
>> We could require that any PostgreSQL that wants to use FDO have a
>> "template_gis" set up already, that would certainly be the simplest
>> solution.  Note that extras/template_gis already exists in the PostGIS
>> distribution, presumably to solve similar problems with packaging in
>> Debian.
>>
>> If we asked Mark Cave-Ayland to add the creation of a template_gis to
>> the Windows installer now, by the time we get to release of the FDO, we
>> could have a large portion of our problems solved.
> 
> I agree, template_gis requirement is the simples solution I can see
> at the moment.
> 
> Cheers