Opened 8 years ago

Closed 3 years ago

Last modified 3 years ago

#27437 closed Bug (wontfix)

Can't create GinIndex on ArrayField(CITextField)

Reported by: Davide Setti Owned by: Mads Jensen
Component: contrib.postgres Version: dev
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

Description

I have a model like:

class MyModel(models.Model):
    column = ArrayField(
        CITextField(max_length=255),
    )

    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 (8)

comment:1 by Tim Graham, 8 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Mads Jensen, 8 years ago

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 by Mads Jensen, 8 years ago

comment:4 by Mads Jensen, 8 years ago

Has patch: set

comment:5 by Simon Charette, 8 years ago

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 8 years ago by Simon Charette (previous) (diff)

comment:6 by Mads Jensen, 8 years ago

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

comment:7 by Tim Graham, 8 years ago

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.

comment:8 by Mariusz Felisiak, 3 years ago

Resolution: wontfix
Status: assignedclosed

It's niche. Moreover the citext extension is ​discouraged since PostgreSQL 12 in favor of non-deterministic collations that are supported in Django 3.2+ via the new db_collation argument for CharField and TextField (see #31777).

Last edited 3 years ago by Mariusz Felisiak (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top