Opened 8 years ago
Closed 8 years ago
#28783 closed New feature (duplicate)
Allow specifying custom operator classes for PostgreSQL indexes
| Reported by: | vinay karanam | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 2.0 |
| Severity: | Normal | Keywords: | postgres, operator class |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
This is an extension of #28077 to support specifying operator class for indexes.
Usage:
Index(fields=['jsonfield'], index_name='jsonb_idx', operator_class='jsonb_path_ops')
Change History (6)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
AFAICT, this is only supported on psql. I am unable to find similar feature on other databases.
I've updated the corresponding documentation.
comment:4 by , 8 years ago
Is there a need for a separate ticket from #28077? (Is there some additional work needed to close that or could we just retitle it?)
I'm unsure if adding database-specific kwargs like operator_class to Index.__init__() is a good approach, but I don't have an alternative in mind.
comment:5 by , 8 years ago
#28077 requires almost same amount of work. It is only asking operator support for GinIndex, whereas this adds support for any postgres index. We can close it in favour of this or retitle #28077 and close this ticket.
Regarding code changes, even I was skeptical at first about adding operator_class to Index.__init__() but then I saw Index.create_sql accepts using kwarg which is only valid for postgres index.
If necessary we can have a subclass PGIndex and move postgres specific options into this.
comment:6 by , 8 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
| Summary: | Support for custom operator class for indexes → Allow specifying custom operator classes for PostgreSQL indexes |
Okay, I added the details from this ticket to #28077 and retitled it.
Is this only supported on PostgreSQL? Of course, documentation would also be needed.