Opened 10 months ago

Closed 10 months ago

Last modified 9 months ago

#35136 closed New feature (wontfix)

Interoperability with intarray PostgreSQL extension

Reported by: Jan Hamal Dvořák Owned by:
Component: contrib.postgres Version: dev
Severity: Normal Keywords: postgresql, intarray
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

django.contrib.postgres.lookups makes use of bare &&, <@ and @> operators. The intarray extension defines it's own set of these operators specific to int4[]. When using __overlap and such on a column with int2[], PostgreSQL does not know what operator to use (cannot decide between casting to int4[] and using the generic version) and fails with "operator is not unique" error.

This ambiguity could be resolved by using OPERATOR(pg_catalog.&&) and such instead of bare && within the django.contrib.postgres.lookups module.

We have locally worked around the issue by changing the operators upon startup, but we are not very comfortable with live-patching Django classes as a long-term solution.

Attachments (1)

intarray-compat.patch (849 bytes ) - added by Jan Hamal Dvořák 10 months ago.
Proposed change

Download all attachments as: .zip

Change History (3)

by Jan Hamal Dvořák, 10 months ago

Attachment: intarray-compat.patch added

Proposed change

comment:1 by Simon Charette, 10 months ago

Resolution: wontfix
Status: newclosed

Thank you for your report.

I don't think that Django can commit to producing SQL that is compatible with all the combination of usage of Postgres extensions out there.

Since it allows for any lookups to be overridden it should be trivial to write your own subclass of ArrayContains and friends and register them on ArrayField.

from django.contrib.postgres.fields.array import ArrayContains

class ArrayContainsOperator(ArrayContains):
   postgres_operator = "OPERATOR(pg_catalog.@>)"

ArrayField.register_lookup(ArrayField.register_lookup)

comment:2 by Jan Hamal Dvořák, 9 months ago

Thank you for a timely reply.

I don't think that Django can commit to producing SQL that is compatible with all the combination of usage of Postgres extensions out there.

I feel this is somewhat unfair. I am not asking for perfect support of every possible extension out there. Django already supports multiple PostgreSQL extensions. The intarray is another one of the handful of extensions bundled with PostgreSQL and available out of the box on mainstream Linux distributions. It doesn't feel like a stretch to expect Django won't break if I enable it, but I won't press you.

Thanks for a cleaner workaround.

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