Opened 16 months ago

Last modified 16 months ago

#27147 new New feature

Add support for defining bounds in postgres range fields

Reported by: Kirill Stepanov Owned by:
Component: contrib.postgres Version: master
Severity: Normal Keywords: postgres range bounds
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Django supports postgres range types in the contrib package, but the bounds are restricted to the default value of "[)" (inclusive low value, exclusive high value) in psycopg2. I propose that django add support for all bounds types - "[]", "(]", "[)" and "()".

Psycopg2 documentation on the matter: http://initd.org/psycopg/docs/extras.html?highlight=range#range-data-types
Postgres documentation on the syntax: https://www.postgresql.org/docs/9.2/static/rangetypes.html#RANGETYPES-IO

I think this could easily be implemented via another argument to the range field type contructor which could be passed down to the psycogp2 range type whenever it's created. Everything else should be automatic after that. Some validation is probably a good idea too.

If people think this is a useful feature, I'll try to write a patch.

Change History (4)

comment:1 Changed 16 months ago by Tim Graham

Can you give a use case to demonstrate exactly how this would work? See also #26345.

comment:2 in reply to:  1 Changed 16 months ago by Kirill Stepanov

Replying to timgraham:

Can you give a use case to demonstrate exactly how this would work? See also #26345.

That ticket only refers to the documentation, not adding ability to override.

My use-case is for date ranges. It's often more natural to have inclusive ranges ([]) than the default [). For example it would make more sense that is something active for a month to start on the first and end on the last day of the month rather than the first of the next month, no?

I recently converted a model from a lower/upper bound pair of date fields to a DateRange to take advantage of the gist index overlap exclusion but had to give up this natural property. I was hoping to implement the ability to do any type of bounds in django to bring the functionality back. Of course even for dates this is not always most optimal - hotel reservations make more sense with a [) range as people can check-in on the same day that others check out in the same room.

Anyway that's my 2¢.

comment:3 Changed 16 months ago by Tim Graham

Triage Stage: UnreviewedAccepted

Is this about form fields and/or model fields? How does it interact with the fact that for some types, "PostgreSQL always returns a range in a canonical form that includes the lower bound and excludes the upper bound; that is [)." as the documentation ticket says. Accepting because the idea seems sensible, however, I would like to see a patch to make a final evaluation of the idea.

comment:4 in reply to:  3 Changed 16 months ago by Kirill Stepanov

Replying to timgraham:

Is this about form fields and/or model fields? How does it interact with the fact that for some types, "PostgreSQL always returns a range in a canonical form that includes the lower bound and excludes the upper bound; that is [)." as the documentation ticket says. Accepting because the idea seems sensible, however, I would like to see a patch to make a final evaluation of the idea.

Ah, I saw that but misunderstood as "no matter how it was originally inserted, django will always interpret incoming data as [) because it doesn't know any better. I now see that postgres canonicalizes discrete ranges but I'll see what I can do about it. The proposal still at least makes sense for non-discrete ranges.

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