Fix variant in UUIDv7

[vmercierfr]

Objective

Fix variant field in UUIDv7 generated by PostgreSQL partition Manager

Why

PPM is currently generating UUIDv7 with variant field set to 0, which is reserved for Network Computing System (NCS) backward compatibility.

UUIDv7 should be use lowest variant as boundary for partition to comply with RFC9562. PostgreSQL implemented the RFC9562 and expect variant 8 (PostgreSQL 18 source code)

In current implementation, UUIDv7 are not valid so timestamp could not be extracted

postgres=# select uuid_extract_timestamp('019d50a3-b800-7000-0000-000000000000');
 uuid_extract_timestamp 
------------------------
 
(1 row)

With new implementation, PostgreQL built-in uuid_extract_timestamp() function correctly resolve UUIDv7 timestamp

postgres=# select uuid_extract_timestamp('019d50a3-b800-7000-8000-000000000000');
 uuid_extract_timestamp 
------------------------
 2026-04-03 00:00:00+00
(1 row)

How

• Update local development environment to use PostgreSQL 18
• Update FromTime() function to generate UUIDv7 with variant field set to 8 (lower bound)
• Update tests and local environments

Release

Release v1.2.0

[vmercierfr]

@dverite as discussed during PostgreSQL meetup, the variant is not valid.

This change do not brake existing partitioning as previous implementation was allowing invalid UUIDv7 and should not be used. However for sake of clarity, I'll add a migration script, but feel free to have a first look.

[dverite]

LGTM
About it being a bug, it's not that bad. The uuid comparison function in postgres does not care about the semantics of the bit fields and the conformance to RFC9562.
So when partition boundaries have the variant bits to 00 instead of 10, aside from the fact that they cannot be passed directly to uuid_extract_timestamp(), it does not seem to make any significant difference for the rest.