id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
31872	Postgres DecimalRangeField ignores bounds	Jack Delany		"Found in 2.2, still in master.

I believe there is an issue in the internal conversion/prep routine for Range types.
{{{
from django.contrib.postgres.fields.ranges import DecimalRangeField

class OneModel(models.Model):
    val = DecimalRangeField()
}}}

Given a simple object created from a tuple:
{{{
x = OneModel(val=(1.0, 2.0, ""[]""))
x.save()
}}}
This emits the following SQL with an incorrect bounds:
{{{
INSERT INTO ""app_onemodel"" (""val"") VALUES ('[1.0,2.0)')  ...
}}}

Alternately:
{{{
from psycopg2.extras import NumericRange
x = OneModel(val=NumericRange(1.0, 2.0, ""[]""))
x.save()
}}}
This one does what I expect and emits the following SQL and preserves the bounds:
{{{
INSERT INTO ""app_onemodel"" (""val"") VALUES ('[1.0,2.0]')  ...
}}}
I tracked it down to:
{{{
django/contrib/postgres/fields/ranges.py:74:

    def get_prep_value(self, value):
        if value is None:
            return None
        elif isinstance(value, Range):
            return value
        elif isinstance(value, (list, tuple)):
            # Problem is here
>>>>        return self.range_type(value[0], value[1])
            # Better:    return self.range_type(*value)
        return value
}}}

Given that get_prep_value() is calling through to the underlying psycopg2 object, I'd presume the intention is that the behavior matches the underlying psycopg2 semantics.

Same pattern is found at line 86 in the ```RangeField.to_python()``` method.

I realize that by using (*value) it'll change the behavior if someone has been passing tuples/list with more than three items, but the behavior seems wrong in that case to silently ignore the extra items.  One could be more explicit and handle the two-item and three-item tuple/list cases individually.  That would minimize the changes.

There is another case #27147 that is related.  In my experience, Ranges generally work correctly and they do have the underlying Postgres behavior (eg bounds normalizing for discreet ranges) so I'm not completely clear what the issue is that  #27147 is trying to address.
"	New feature	closed	contrib.postgres	3.1	Normal	wontfix			Unreviewed	0	0	0	0	0	0