| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Tristan Partin <tristan(at)partin(dot)io> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support UUIDv6 in uuid_extract_timestamp() |
| Date: | 2026-08-03 19:20:29 |
| Message-ID: | CAD21AoAfrmiRot-8340kQB4i-GGgjtE0wySs_BaRCPjhPr2Ncg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 24, 2026 at 4:29 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin <tristan(at)partin(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tristan Partin | 2026-08-03 19:54:58 | Re: Support UUIDv6 in uuid_extract_timestamp() |
| Previous Message | Masahiko Sawada | 2026-08-03 18:36:11 | Re: Proposal: Conflict log history table for Logical Replication |