Impossible to create indexes on PostGIS fields

[aneil]

I've included a patch which addresses the request below. This adds a signal, final_post_syncdb which enables adding sql commands after all custom sql and indexes and PostGIS columns are created. The patch is with respect to django-trunk

• * *

Please add a "final_post_syncdb" signal. See #7561.

It is currently not possible to add custom SQL which depends on GeoDjango fields. This is because the custom sql appears before the commands which create the PostGIS column.

For example, I'd like to create a multicolumn GiST index on Postgres:

in myapp.models.py:

class Location(Model):
   counter = IntegerField() 
   point = PointField()

in sql/location.sql:

    CREATE INDEX idx_location_point_counter ON main_location USING GIST(point,counter);

results in the error:
Failed to install custom SQL for main.Location model: column "point" does not exist

(Note, that on Postgres, one needs to install contrib/btree_gist.sql to enable GiST indexes on integer fields)

./manage.py sqlall main yields:

CREATE TABLE "main_location" (
    "id" serial NOT NULL PRIMARY KEY,
    "counter" integer
)
;
CREATE INDEX idx_location_point_counter ON main_location USING GIST(point,counter);
SELECT AddGeometryColumn('main_location', 'point', 4326, 'POINT', 2); 

The problem is in the last two lines: the sql refers to the point column before it's created.

Unfortunately, the post_syncdb signal is no help either, since this is also sent before the PostGIS commands are generated.

[jbronn]

I agree this is a problem, but I'm -1 at the patch in it's current form, as I'm not sure it's the correct approach. Apologies for the vague feedback, but this is probably a bigger issue that'll need some django-dev discussion time.

[Paul Winkler]

I tried provoking some django-dev discussion (​http://groups.google.com/group/django-developers/browse_frm/thread/b1665b5526f4802b/60e99380e64ecd7f?lnk=gst&q=winkler#60e99380e64ecd7f)
and got nothing. I don't have a better patch idea. Any way we can make progress on this?

[Russell Keith-Magee]

Closing as a duplicate of #7561. The requirements of PostGIS presents a specific use case, but doesn't change the fact that #7561 is about rationalizing the syncdb behavior. Whatever solution we come up with for #7561 should be able to accomodate this use case.