#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)
Change History (3)
by , 10 months ago
Attachment: | intarray-compat.patch added |
---|
comment:1 by , 10 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 , 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.
Proposed change