Support unbounded ranges

[nicoleepp]

WIP because this is waiting on invenia/Intervals.jl#104

[omus]

Another invalid test:

Suggested change

	("'(,3]'::int4range", Interval{Unbounded, Open}(nothing, Int32(4))),
	("'(,3]'::int4range", Interval{Unbounded, Closed}(nothing, 3)),

[nicoleepp]

This is how postgres stores that in the db. Changing it to your suggestion doesn't work:

(test_str, data) = ("'(,3]'::int4range", Interval{Int32,Unbounded,Closed}(nothing, 3)): Test Failed at /Users/nicoleepp/.julia/dev/LibPQ/test/runtests.jl:1191
  Expression: isequal(parsed, data)
   Evaluated: isequal(Interval{Int32,Unbounded,Open}(nothing, 4), Interval{Int32,Unbounded,Closed}(nothing, 3))

[omus]

Very interesting. This seems to only apply to the upper endpoint.

omus=# SELECT '(,3]'::int4range;
 int4range
-----------
 (,4)
(1 row)

I would suggest at least adding a comment about this as it is rather strange. I'll see if I can find out more about this.

Suggested change

	("'(,3]'::int4range", Interval{Unbounded, Open}(nothing, Int32(4))),
	("'(,3]'::int4range", Interval{Unbounded, Open}(nothing, Int32(4))), # Postgres normalizes the range `(,3]` to `(,4)`

[omus]

I didn't find anything official but I believe what is going on here is that PostgreSQL is normalizing the range (see the last example in https://www.postgresql.org/docs/9.3/rangetypes.html#RANGETYPES-IO).

omus=# SELECT '[4,4)'::numrange;  -- includes no points (and will be normalized to 'empty')
 numrange
----------
 empty

Since we're using int4range here PostgreSQL can change the interval as it knows the possible values that are included in the interval. We can see this in action by making an interval set that just contains 4:

omus=# SELECT '[4,4]'::int4range;
 int4range
-----------
 [4,5)
(1 row)

omus=# SELECT '(3,4]'::int4range;
 int4range
-----------
 [4,5)
(1 row)

omus=# SELECT '[4,5)'::int4range;
 int4range
-----------
 [4,5)
(1 row)

omus=# SELECT '(3,5)'::int4range;
 int4range
-----------
 [4,5)
(1 row)

Finally, for ranges which the sets are not so clearly defined no normalization should occur which is the case:

omus=# SELECT '[4.0,4.0]'::numrange;
 numrange
-----------
 [4.0,4.0]
(1 row)

[nicoleepp]

Documentation job is running into JuliaPackaging/Yggdrasil#1203