Interoperability with intarray PostgreSQL extension

[Jan Hamal Dvořák]

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.

[Jan Hamal Dvořák]

Proposed change

[Simon Charette]

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)

[Jan Hamal Dvořák]

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.