Opened 14 years ago

Closed 13 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: no UI/UX: no

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 14 years ago.

Download all attachments as: .zip

Change History (5)

by aneil, 14 years ago

Attachment: final_post_sync.diff added

comment:1 by jbronn, 14 years ago

Description: modified (diff)

comment:2 by jbronn, 14 years ago

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 by Paul Winkler, 14 years ago

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 by Russell Keith-Magee, 13 years ago

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