Opened 22 months ago

Last modified 21 months ago

#27437 assigned Bug

Can't create GinIndex on ArrayField(CITextField)

Reported by: Davide Setti Owned by: Mads Jensen
Component: contrib.postgres Version: master
Severity: Normal Keywords: postgres, indexes, gin, citext, arrays
Cc: Triage Stage: Someday/Maybe
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I have a model like:

class MyModel(models.Model):
    column = ArrayField(

    class Meta:
        indexes = [
            GinIndex(fields=['column'], name='mygin')

Migration fails because:

django.db.utils.ProgrammingError: data type citext[] has no default operator class for access method "gin"
HINT:  You must specify an operator class for the index or define a default operator class for the data type.

full trace on this gist. To solve this issue an Operator Class must be created

Change History (7)

comment:1 Changed 22 months ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:2 Changed 21 months ago by Mads Jensen

Owner: set to Mads Jensen
Status: newassigned

I have some code, tests, and documentation for this, although the SQL code from Stackoverflow appears to be incorrect (I get django.db.utils.InternalError: ginqueryarrayextract: unknown strategy number: 7).

comment:3 Changed 21 months ago by Mads Jensen

comment:4 Changed 21 months ago by Mads Jensen

Has patch: set

comment:5 Changed 21 months ago by Simon Charette

As I mentioned to the reporter at DUTH I'm not convinced this a common enough use case to ship and maintain a custom operation class. The fact that the citext extension doesn't ship with these operator classes itself makes be doubt it's commonly used.

I'd be in favor of moving the ticket to Someday/Maybe and see if this gather any traction as both GINIndex and CITextField are new features in the still unreleased Django 1.11.

Last edited 21 months ago by Simon Charette (previous) (diff)

comment:6 Changed 21 months ago by Mads Jensen

I'm a bit indifferent to how this will get treated.

comment:7 Changed 21 months ago by Tim Graham

Triage Stage: AcceptedSomeday/Maybe

Yes, this looks a bit specialized. In my opinion, contrib.postgres should aim for implementing things that are an ~80% use case. As Simon said, it would be nice to have more evidence that this is common before committing to include it. Anyway, the code is on the pull request for anyone who would like to use it in their own project.

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