Add support for unbounded intervals

[nicoleepp]

Add support for unbounded intervals

[iamed2]

IMO the result of span on [x,), [x,∞) and [x,∞] should all be the same. I think the error on unbounded intervals is a reasonable choice for now if we don't have a good way to implement that.

[omus]

Originally the plan was to use nothing to represent an interval that was unbounded. However, when implementing this design we ran into troubles when implementing span (the distance between the endpoints) for an unbounded interval. In this particular case it make the most sense to return some kind of infinity value. The current approach is to try and integrate Infinity.jl and see if we can add an infinity value for TimeTypes.

[omus]

Some rules around unbounded intervals that were though of during an initial design:

• For unbounded intervals span should return infinity
• If the lower bound of a interval is unbounded then all points less than the upper bound are included in the interval
• If the upper bound of an interval is unbounded then all points greater than the lower bound are included in the interval
• When considering unbounded range's inclusiveness we should consider if infinity should be considered contained within the interval. e.g. ∞ in [0,∞) == false as infinity is not actually included in this interval. More specifically all positive finite values are included in the interval but infinity is not.
• An AnchoredInterval uses one point and a span to calculate the other endpoint. Conversion from an Interval that uses one finite endpoint and another non-finite endpoint is impossible if the non-finite endpoint is the one used for the AnchoredInterval. This is because it would be impossible to calculate the other endpoint from the single non-finite endpoint.

[omus]

After a discussion with @iamed2 it should be mentioned that intervals using infinity as an endpoint are not necessarily unbounded intervals. As mentioned in the last post [0,∞) is a good example of this.

Take note that PostgreSQL supports timestamp ranges with infinity (e.g. [today,infinity], [today,infinity)) and supports unbounded ranges (e.g. [today,)). The main advantage I see of not relying on infinity for unbounded interval support is that you don't require the element type of the interval to have a representation for infinity meaning we unbounded support will work for more types and not require special type extensions like Infinity.jl provides.

Furthermore, if we use as the [today,infinity] unbounded interval what should LibPQ.jl do when inserting into PostgreSQL? Most likely [today,infinity] should be inserted which leaves us no way to insert [today,) without a special flag.

The problem with special unbounded interval approach gets back to the issue with span. With unbounded intervals what should be returned when the element type is say: Int, Char, or Float64? The first two examples don't have a representation of infinity for those types which leaves (I believe) three options:

1. Have a special type that represents +/- infinity. Effectively this is what Infinity.jl does but we could would probably only represent infinity without the extension support. Probably:

   struct Infinity{T}
       sign::Bool
   end

2. Have a special type from 1 but use the infinity representation of the current type one is available. We'd need an inf(::Type{T}) for general support

3. Raise an exception when using span on unbounded ranges. To support generic interval coding we'd also supply an isunbounded function which allows us to avoid raising the exception. This allows the user to supply their own representation of infinity if they require this behaviour. I'll note this approach also seems the safest as it will be easier to move away from this approach in the future

I am personally leaning towards 3 as the best option as it appears the simplest.