Opened 10 months ago
Closed 10 months ago
#36045 closed New feature (wontfix)
Add Support for PostgreSQL Infinity and -Infinity in Date/Time Fields — at Version 2
| Reported by: | Kavin Bharathi | Owned by: | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 5.1 |
| Severity: | Normal | Keywords: | postgres, infinity, datetime |
| Cc: | Kavin Bharathi | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Proposed Feature:
- Add support for parsing PostgreSQL's infinity and -infinity values into Django models.
- Represent infinity and -infinity using custom Python objects or constants (e.g., django.db.utils.Infinity and -Infinity).
- Ensure seamless integration with Django's ORM for querying, inserting, and updating fields containing these values.
- Provide a mechanism to serialize and deserialize these values (e.g., JSON serialization).
Use Cases:
- Handling open-ended event durations.
- Representing date ranges without a start or end boundary.
- Supporting applications that already use these values in their PostgreSQL databases.
Benefits:
- Enables Django developers to work with PostgreSQL databases more effectively.
- Expands Django's compatibility with PostgreSQL's advanced features.
Potential Challenges:
- Ensuring backward compatibility with existing applications.
- Deciding on a Python representation for infinity that integrates well with Django's ORM and other Python libraries.
References:
Change History (2)
comment:1 by , 10 months ago
| Keywords: | postgres infinity datetime added |
|---|
comment:2 by , 10 months ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Thanks for the proposal, however, I don't think we can accept it without a consensus on the Django Forum. As you note, there are a lot of open questions about how it could be implemented, so the design proposal would need to be solid. It's also unclear if it's a good idea to expose a database-specific feature like this that - as far as I'm aware - only applies to PostgreSQL. If you want to pursue this, I would try to implement it as a custom field so you can better understand what changes are required. Then, if you believe the changes should be incorporated in Django, make your proposal on the forum.