Describe the use case
The SA Range does not have an exact notion of its "type", i.e. there is no way to determine the data type of an empty
or infinite range.
Databases / Backends / Drivers targeted
The Range class is specific to PostgreSQL, but is driver-agnostic.
Example Use
For example, my app shows the period of validity of (say) a contract, which storage is a daterange, either in a compact form (mm/dd/yy - mm/dd/yy) or as a more verbose, human friendly message ("from Sun, 10 March 2022 to Fri, 15 March 2022"), in multiple languages, and taking into account "infinite" variants. This was implemented with a generic strftime() function taking either a date, a datetime, a DateRange or DateTimeRange as argument, and depending on the kind it used different gettext() messages to translate it to a string.
To emit different messages for "endless" date ranges and "endless" datetime ranges, I had to modify the code path leading there, to bring over the "original" kind of the range.
This could help also in the recently added tests, where we had to invent a way to distinguish the different kind of ranges to be able to determine a "discrete step" for each of them.
Additional context
In an exchange on the ML, Mike suggested to add a type attribute to the Range class, with possibly a set of helper constructors, say classmethods like Range.new_date_range().
Describe the use case
The SA Range does not have an exact notion of its "type", i.e. there is no way to determine the data type of an empty
or infinite range.
Databases / Backends / Drivers targeted
The
Rangeclass is specific to PostgreSQL, but is driver-agnostic.Example Use
For example, my app shows the period of validity of (say) a contract, which storage is a
daterange, either in a compact form (mm/dd/yy - mm/dd/yy) or as a more verbose, human friendly message ("from Sun, 10 March 2022 to Fri, 15 March 2022"), in multiple languages, and taking into account "infinite" variants. This was implemented with a genericstrftime()function taking either a date, adatetime, aDateRangeorDateTimeRangeas argument, and depending on the kind it used differentgettext()messages to translate it to a string.To emit different messages for "endless" date ranges and "endless" datetime ranges, I had to modify the code path leading there, to bring over the "original" kind of the range.
This could help also in the recently added tests, where we had to invent a way to distinguish the different kind of ranges to be able to determine a "discrete step" for each of them.
Additional context
In an exchange on the ML, Mike suggested to add a
typeattribute to theRangeclass, with possibly a set of helper constructors, say classmethods likeRange.new_date_range().