Feature/test mutually exclusive ranges

[clrcrl]

Test failing because of this issue. Will wait for that fix rather than working around the issue.

[jthandy]

@drewbanin I'm not going to be able to look at this for like another week. Any chance you're able to help out here? Sorry, I know I'm useless right now.

[drewbanin]

This is groovy! Couple of small comments, but largely LGTM.

I think the logic in the where clause could benefit from additional attention to better handle cases when lower_bound_column or upper_bound_column are errantly null. Keen to discuss!

Also: That CI issue should be resolved - the tests should run on your next push

[drewbanin]

is this correct? It seems like you did the opposite of this in the code below! I think it would make sense to put one big not around the entire predicate

[clrcrl]

Rewrote this to make it cleaner

[clrcrl]

A few other things:

1. Is mutually_exclusive the right term here? Is it known enough? Should we call it non_overlapping_ranges instead?
2. I thought about getting extremely persnickety and implementing three operators, i.e.:

gaps:not_allowed --> lower_bound  = previous_upper_bound
gaps:allowed     --> lower_bound <= previous_upper_bound
gaps:required    --> lower_bound <  previous_upper_bound

example of gaps:not_allowed:

lower_bound	upper_bound
0	1
1	2
2	3

example of gaps:allowed

lower_bound	upper_bound
0	1
2	3
3	4

example of gaps:required

lower_bound	upper_bound
0	1
2	3
4	5

There's probably a better way to express that, not sure if it's worth implementing. I can imagine ranges (especially timestamp ones) where you actually want things to not overlap so you don't have a fan out in any downstream joins, but 🤷‍♀

3. Should there be an extra optional arg for order_by? I just assumed you could order by the lower_bound, which feels pretty safe for now.
   Never mind -- making the lower_bound not null means that this is a reasonable assumption!

[drewbanin]

This looks excellent - ship it!