PostGIS DB creation SQL not found on Fedora-based installs.

[alexdutton]

Django looks for lwpostgis.sql and spatial_ref_sys.sql in "pg_config --sharedir", but they are kept in "pg_config --sharedir/contrib" on Fedora systems. Additionally, lwpostgis.sql is renamed lwpostgis-64.sql on 64-bit machines.

The attached patch results in Django looking in more than one place before giving up.

[alexdutton]

SVN diff of changes to check more than one location for postgis files.

[adamfast]

This is probably best fixed through a bit better documentation explaining that POSTGIS_SQL_PATH is usable in these circumstances.

It discusses it here ​http://geodjango.org/docs/testing.html?highlight=postgis_sql_path#postgis-sql-path in the context of testing. Are you running tests or doing something else? Either way, that option in your settings file will make it work without any code changes.

The reality is a lot of distros and OSes will keep these files in all sorts of different places, and it's not really appropriate to build up a "database" of sorts on where each of them could be. Default it to something (or even take away the default - and when the setting isn't set complain) but make it easily changeable, which it already is.

[alexdutton]

Replying to adamfast:

This is probably best fixed through a bit better documentation explaining that POSTGIS_SQL_PATH is usable in these circumstances.

It discusses it here ​http://geodjango.org/docs/testing.html?highlight=postgis_sql_path#postgis-sql-path in the context of testing. Are you running tests or doing something else? Either way, that option in your settings file will make it work without any code changes.

Okay; I didn't see that one. It doesn't help in the context of lwpostgis-64.sql though. And yes, I'm running tests.

The reality is a lot of distros and OSes will keep these files in all sorts of different places, and it's not really appropriate to build up a "database" of sorts on where each of them could be. Default it to something (or even take away the default - and when the setting isn't set complain) but make it easily changeable, which it already is.

I'll agree that in retrospect my solution is suboptimal.

Trying to find files that may go AWOL and then passing them to psql has another problem in that it prompts for the database password (which is in the settings module) three times when running tests. The installation instructions for GeoDjango suggest creating a template and then creating the development/production database from there. Would it therefore make sense to create the test database from the same template? There would then be a POSTGIS_TEMPLATE_NAME which would default to 'template_postgis', with documentation to say that the template is expected when running tests. This could be done within psycopg2, removing the need to enter passwords manually.

[jbronn]

Replying to alexdutton:

Would it therefore make sense to create the test database from the same template? There would then be a POSTGIS_TEMPLATE_NAME which would default to 'template_postgis', with documentation to say that the template is expected when running tests. This could be done within psycopg2, removing the need to enter passwords manually.

This setting already exists, and is POSTGIS_TEMPLATE. Thus set POSTGIS_TEMPLATE='template_postgis' in your settings and the test runner should be fine, even on Fedora.

I'll update the testing docs to instruct users to use a template for testing because (i) its faster and (ii) the release of PostGIS 1.4 changed the file name to postgis.sql anyways. Because the template db is the way to go, I'm -1 on having a db of PostGIS locations because some distro is always going to be missing. I'll keep this ticket open until the docs have changed, but I otherwise do not plan on applying this patch absent a convincing argument to the contrary.

[jbronn]

​Testing docs have been updated with a note recommending use of POSTGIS_TEMPLATE.