Support (time) partitioning on UUIDv7

[erimatnor]

Add initial support for (time) partitioning a hypertable on a UUID column. Only version 7 UUIDs are currently supported because of their time ordering properties using the embedded Unix timestamp. Inserting a non-v7 UUID generates an error. This might be relaxed in the future.

Chunk exclusion and filtering on a UUID column work as expected. However, native UUID support for query functions, such as time_bucket and gapfill, is not added as part of this change.

Resolves: #7682

[codecov]

Codecov Report

❌ Patch coverage is 86.95652% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.36%. Comparing base (3fdd739) to head (f786971).
⚠️ Report is 39 commits behind head on main.

Files with missing lines	Patch %	Lines
src/time_utils.c	75.00%	2 Missing ⚠️
src/utils.c	88.88%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8505      +/-   ##
==========================================
+ Coverage   82.29%   82.36%   +0.06%     
==========================================
  Files         248      248              
  Lines       47544    47533      -11     
  Branches    12077    12076       -1     
==========================================
+ Hits        39128    39149      +21     
- Misses       3507     3529      +22     
+ Partials     4909     4855      -54     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fabriziomello]

LGTM

[msqr]

Hey @erimatnor I'm pleased to see UUIDv7 support making its way in, thank you very much! I noticed your comments in the code:

Since RFC9562 specifies the timestamp as unsigned, the minimum value is
0. Further, the sub-millisecond part cannot be used as time since the bits
are optional and it is not possible to know if they are random or represent
a time fraction. Therefore, the max value is limited to the milliseconds.

and wondered if it would be possible to support the optional fractional millisecond part of the spec by way of some Hypertable configuration, or even a GUC, that asserts that all UUIDs can be treated as such?

[erimatnor]

Hey @erimatnor I'm pleased to see UUIDv7 support making its way in, thank you very much! I noticed your comments in the code:

Since RFC9562 specifies the timestamp as unsigned, the minimum value is
0. Further, the sub-millisecond part cannot be used as time since the bits
are optional and it is not possible to know if they are random or represent
a time fraction. Therefore, the max value is limited to the milliseconds.

and wondered if it would be possible to support the optional fractional millisecond part of the spec by way of some Hypertable configuration, or even a GUC, that asserts that all UUIDs can be treated as such?

Hey @erimatnor I'm pleased to see UUIDv7 support making its way in, thank you very much! I noticed your comments in the code:

Since RFC9562 specifies the timestamp as unsigned, the minimum value is
0. Further, the sub-millisecond part cannot be used as time since the bits
are optional and it is not possible to know if they are random or represent
a time fraction. Therefore, the max value is limited to the milliseconds.

and wondered if it would be possible to support the optional fractional millisecond part of the spec by way of some Hypertable configuration, or even a GUC, that asserts that all UUIDs can be treated as such?

@msqr The functions we provide to generate UUIDs will add fractional milliseconds by default. There's also an option to extract the higher-precision timestamp if one knows those bits encode time.