Opened 6 years ago

Closed 6 years ago

#13826 closed (duplicate)

Impossible to create indexes on PostGIS fields

Reported by: aneil Owned by: jbronn
Component: GIS Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description (last modified by jbronn)

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:


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)

./ 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.

Attachments (1)

final_post_sync.diff (3.1 KB) - added by aneil 6 years ago.

Download all attachments as: .zip

Change History (5)

Changed 6 years ago by aneil

Attachment: final_post_sync.diff added

comment:1 Changed 6 years ago by jbronn

Description: modified (diff)
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:2 Changed 6 years ago by jbronn

Owner: changed from nobody to jbronn
Patch needs improvement: set
Status: newassigned

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.

comment:3 Changed 6 years ago by Paul Winkler

I tried provoking some django-dev discussion (
and got nothing. I don't have a better patch idea. Any way we can make progress on this?

comment:4 Changed 6 years ago by Russell Keith-Magee

Resolution: duplicate
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top