Support UUIDv6 in uuid_extract_timestamp()
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t248627psql -h localhost -U postgresBuilt from patchset v6 (message #6), August 03, 2026 at 08:08 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t248627_6 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t248627_6 && git checkout t248627_6Patchset v6 (message #6) is on t248627_6
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.
Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
Attachments:
t248627_1v1-0001-Support-UUIDv6-in-uuid_extract_timestamp.patchtext/x-patch; charset=utf-8; name=v1-0001-Support-UUIDv6-in-uuid_extract_timestamp.patchDownload+25-2
v1-0002-Add-comments-to-uuid_extract_timestamp.patchtext/x-patch; charset=utf-8; name=v1-0002-Add-comments-to-uuid_extract_timestamp.patchDownload+33-1
On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.
Thank you for the patch!
The patch seems reasonable to me. I'll review the patch in depth.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Hi,
On Sunday, 26 July 2026 at 18:05, Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.
Makes sense, this would be the last missing piece in uuid_extract_timestamp(). The code itself looks good.
Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.
I think it's a good idea. Now it's much easier to understand what's going on with these wild manipulations.
On Sun Jul 26, 2026 at 4:38 PM UTC, Miłosz Bieniek wrote:
Hi,
On Sunday, 26 July 2026 at 18:05, Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.Makes sense, this would be the last missing piece in uuid_extract_timestamp(). The code itself looks good.
Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.I think it's a good idea. Now it's much easier to understand what's going on with these wild manipulations.
Thanks for the review.
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
On Wed, Jun 24, 2026 at 4:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.Thank you for the patch!
The patch seems reasonable to me. I'll review the patch in depth.
I've reviewed the v1 patches and the 0001 patch looks good to me. I
have one comment for the 0002 patch:
+ /*
+ * UUIDv1 splits the 60-bit Gregorian timestamp into three fields that
+ * are *not* stored most-significant-first (see RFC 9562 sec. 5.1):
+ *
+ * time_low (bits 0-31) octets 0-3, the least significant 32 bits
+ * time_mid (bits 32-47) octets 4-5, the middle 16 bits
+ * time_high (bits 48-59) octet 6 low nibble + octet 7, the most
+ * significant 12 bits (octet 6 high nibble
+ * holds the version and is masked off)
+ *
+ * Reassemble the timestamp by shifting each field back to its place.
+ */pgindent destroys these field tables. We need to tell pgindent to
leave the block alone by adding the dashed comment form:
/*----------
* UUIDv6 is a field-compatible reordering of UUIDv1 that stores the
...
*----------
*/
Or I guess that this part doesn't necessarily need to be such a
format. Simply writing it like follow would work too:
/*
* UUIDv1 stores the 60-bit Gregorian timestamp in three fields that
* are *not* in most-significant-first order (RFC 9562 sec. 5.1):
* octets 0-3 hold the least significant 32 bits, octets 4-5 the
* middle 16, and octet 6's low nibble plus octet 7 the most
* significant 12. Octet 6's high nibble is the version, masked off
* below. The shifts put each field back in its place.
*/
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Mon Aug 3, 2026 at 7:21 PM UTC, Masahiko Sawada wrote:
On Wed, Jun 24, 2026 at 4:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.Thank you for the patch!
The patch seems reasonable to me. I'll review the patch in depth.
I've reviewed the v1 patches and the 0001 patch looks good to me. I
have one comment for the 0002 patch:+ /* + * UUIDv1 splits the 60-bit Gregorian timestamp into three fields that + * are *not* stored most-significant-first (see RFC 9562 sec. 5.1): + * + * time_low (bits 0-31) octets 0-3, the least significant 32 bits + * time_mid (bits 32-47) octets 4-5, the middle 16 bits + * time_high (bits 48-59) octet 6 low nibble + octet 7, the most + * significant 12 bits (octet 6 high nibble + * holds the version and is masked off) + * + * Reassemble the timestamp by shifting each field back to its place. + */pgindent destroys these field tables. We need to tell pgindent to
leave the block alone by adding the dashed comment form:/*----------
* UUIDv6 is a field-compatible reordering of UUIDv1 that stores the
...
*----------
*/Or I guess that this part doesn't necessarily need to be such a
format. Simply writing it like follow would work too:/*
* UUIDv1 stores the 60-bit Gregorian timestamp in three fields that
* are *not* in most-significant-first order (RFC 9562 sec. 5.1):
* octets 0-3 hold the least significant 32 bits, octets 4-5 the
* middle 16, and octet 6's low nibble plus octet 7 the most
* significant 12. Octet 6's high nibble is the version, masked off
* below. The shifts put each field back in its place.
*/
Thanks for the review. I went with option 1 to fix the comments in the
patch. I think it is a bit more readable than option 2. Included is
a re-spin of the first patch, but it is equivalent to v1. I tested
pgindent myself on v2, and it left the comment block alone.
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
Attachments:
t248627_6v2-0001-Support-UUIDv6-in-uuid_extract_timestamp.patchtext/x-patch; charset=utf-8; name=v2-0001-Support-UUIDv6-in-uuid_extract_timestamp.patchDownload+25-2
v2-0002-Add-comments-to-uuid_extract_timestamp.patchtext/x-patch; charset=utf-8; name=v2-0002-Add-comments-to-uuid_extract_timestamp.patchDownload+35-1
On Mon, Aug 3, 2026 at 12:55 PM Tristan Partin <tristan@partin.io> wrote:
On Mon Aug 3, 2026 at 7:21 PM UTC, Masahiko Sawada wrote:
On Wed, Jun 24, 2026 at 4:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.Thank you for the patch!
The patch seems reasonable to me. I'll review the patch in depth.
I've reviewed the v1 patches and the 0001 patch looks good to me. I
have one comment for the 0002 patch:+ /* + * UUIDv1 splits the 60-bit Gregorian timestamp into three fields that + * are *not* stored most-significant-first (see RFC 9562 sec. 5.1): + * + * time_low (bits 0-31) octets 0-3, the least significant 32 bits + * time_mid (bits 32-47) octets 4-5, the middle 16 bits + * time_high (bits 48-59) octet 6 low nibble + octet 7, the most + * significant 12 bits (octet 6 high nibble + * holds the version and is masked off) + * + * Reassemble the timestamp by shifting each field back to its place. + */pgindent destroys these field tables. We need to tell pgindent to
leave the block alone by adding the dashed comment form:/*----------
* UUIDv6 is a field-compatible reordering of UUIDv1 that stores the
...
*----------
*/Or I guess that this part doesn't necessarily need to be such a
format. Simply writing it like follow would work too:/*
* UUIDv1 stores the 60-bit Gregorian timestamp in three fields that
* are *not* in most-significant-first order (RFC 9562 sec. 5.1):
* octets 0-3 hold the least significant 32 bits, octets 4-5 the
* middle 16, and octet 6's low nibble plus octet 7 the most
* significant 12. Octet 6's high nibble is the version, masked off
* below. The shifts put each field back in its place.
*/Thanks for the review. I went with option 1 to fix the comments in the
patch. I think it is a bit more readable than option 2. Included is
a re-spin of the first patch, but it is equivalent to v1. I tested
pgindent myself on v2, and it left the comment block alone.
Thank you for updating the patches.
Yeah, the current explanation seems better as the terms like
"time_high" matches ones the RFC uses. I'll push these patches barring
any objections.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Mon, Aug 3, 2026 at 3:53 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Mon, Aug 3, 2026 at 12:55 PM Tristan Partin <tristan@partin.io> wrote:
On Mon Aug 3, 2026 at 7:21 PM UTC, Masahiko Sawada wrote:
On Wed, Jun 24, 2026 at 4:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin <tristan@partin.io> wrote:
UUIDv6 is the same as UUIDv1 with some fields reordered. We already
supported UUIDv1, so let's add support for UUIDv6. Previously, calls to
uuid_extract_timestamp() would return NULL for UUIDv6 values.Patch 2 only adds comments. I think the bit manipulation is worthy of
comments, but others may disagree.Thank you for the patch!
The patch seems reasonable to me. I'll review the patch in depth.
I've reviewed the v1 patches and the 0001 patch looks good to me. I
have one comment for the 0002 patch:+ /* + * UUIDv1 splits the 60-bit Gregorian timestamp into three fields that + * are *not* stored most-significant-first (see RFC 9562 sec. 5.1): + * + * time_low (bits 0-31) octets 0-3, the least significant 32 bits + * time_mid (bits 32-47) octets 4-5, the middle 16 bits + * time_high (bits 48-59) octet 6 low nibble + octet 7, the most + * significant 12 bits (octet 6 high nibble + * holds the version and is masked off) + * + * Reassemble the timestamp by shifting each field back to its place. + */pgindent destroys these field tables. We need to tell pgindent to
leave the block alone by adding the dashed comment form:/*----------
* UUIDv6 is a field-compatible reordering of UUIDv1 that stores the
...
*----------
*/Or I guess that this part doesn't necessarily need to be such a
format. Simply writing it like follow would work too:/*
* UUIDv1 stores the 60-bit Gregorian timestamp in three fields that
* are *not* in most-significant-first order (RFC 9562 sec. 5.1):
* octets 0-3 hold the least significant 32 bits, octets 4-5 the
* middle 16, and octet 6's low nibble plus octet 7 the most
* significant 12. Octet 6's high nibble is the version, masked off
* below. The shifts put each field back in its place.
*/Thanks for the review. I went with option 1 to fix the comments in the
patch. I think it is a bit more readable than option 2. Included is
a re-spin of the first patch, but it is equivalent to v1. I tested
pgindent myself on v2, and it left the comment block alone.Thank you for updating the patches.
Yeah, the current explanation seems better as the terms like
"time_high" matches ones the RFC uses. I'll push these patches barring
any objections.
Pushed.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com