Change Log

1. Add functions rb_group_elements_by_source() and rb64_group_elements_by_source() (#66 by @chriswheeldon-peakon)
2. Add operators < <= >= and >
3. Add btree, hash, and GIN index support for roaringbitmap and roaringbitmap64(Fix #24 and #36 by @ChenHuajun).
   < <= = >= > @> <@ &&, ORDER BY, GROUP BY and count(distinct rb) can now use an index.
4. Add custom restriction estimators for @> @< &&, current fixed selectivity settings:
   @> and <@ operators are set to 0.005, && operator is set to 0.01; previous versions used 0.001.
5. Upgrade CRoaring to 5.2.2(Fix #65)
6. Add support of big-endian env such as s390x.(#81)
7. Add rb_jaccard_index() and rb64_jaccard_index().(Fix #78)
   rb_jaccard_dist() and rb64_jaccard_dist() return the Jaccard similarity coefficient,
   not the distance, so their names are misleading; they are deprecated and may be
   removed in a future release, but kept unchanged for backward compatibility.
   Use rb_jaccard_index() instead.
8. Limit the range width of rb64_fill() and rb64_flip() to 2^32 values, and
   range_end = 0 is no longer treated as unlimited in these two functions (Fix #75);
   range_end = 0 still means unlimited in rb64_clear(), rb64_range(),
   rb64_range_cardinality() and rb64_select()
9. Fix rb_range(), rb_range_cardinality() and rb_select(): range_start at or above
   2^32 was silently truncated to its low 32 bits, so the requested range was not
   honored; range_start is now clamped to 2^32, and range_start >= range_end now
   returns an empty result (Fix #76)
10. Fix rb_jaccard_dist() and rb64_jaccard_dist() to return 1 instead of NaN when both
    bitmaps are empty (these functions return the Jaccard similarity coefficient, so two
    empty bitmaps are identical) (Fix #77)

Compatibility Notes

The following behaviour changes are not backward compatible with v1.2.0 and may require application changes.

1. rb_jaccard_dist() and rb64_jaccard_dist() are deprecated and superseded, but kept unchanged for backward compatibility.
   Both functions have always returned the Jaccard similarity coefficient, (∣A∩B∣)/(∣A∪B∣), not a distance,
   so their names are misleading.Use rb_jaccard_index() / rb64_jaccard_index() in new code. The old names
   are kept, remain fully functional, and return exactly the same values as the new ones.

2. rb_jaccard_dist() / rb64_jaccard_dist() / rb_jaccard_index() / rb64_jaccard_index() return 1 instead of NaN for two empty bitmaps.
   Since these functions compute a similarity coefficient, two empty bitmaps are identical and now yield 1.
   Applications that relied on NaN propagation, or that detected the empty/empty case via IS NULL or a NaN comparison, must be updated; ordinary = 0 / > 0 / >= 0.5 comparisons are unaffected.

3. rb64_fill() and rb64_flip(): the filled range is capped at 2^32 values, and range_end = 0 is no longer "unlimited"

   • A range wider than 2^32(4294967296) now raises error instead of attempting the fill. Because a roaringbitmap64 spans the
     entire 64-bit space, an unrestricted fill over a huge range previously consumed unbounded memory and terminated the backend.

   • range_end = 0 is no longer treated as "unlimited" by these two functions: it now makes the call a no-op(previously it filled or
     flipped everything from range_start through the end of the 64-bit space). This is a silently-different result, not an error, so please
     audit any call that passes 0 as range_end.

4. rb_range(), rb_range_cardinality() and rb_select() (32-bit): range_start at or above
   2^32 was silently truncated to its low 32 bits, so the requested range was not
   honored; range_start is now clamped to 2^32, and range_start >= range_end now
   returns an empty result. For example, rb_range('{1,2,3}', 4294967296, 4294967297) now returns {} instead of {1,2,3}.

Other behaviour change worth noting
The built-in selectivity estimates for @>, <@ and && changed from a flat 0.001 to 0.005 (@>, <@) and 0.01 (&&). This is not an API
break, but it will change the plans chosen for some queries that use these operators. Newly added operators (<, <=, >=, >) and
the new btree / hash / GIN index support for both types are purely additive and do not alter the behaviour of existing queries.