Re: Support UUIDv6 in uuid_extract_timestamp()

Поиск
Список
Период
Сортировка
Искать

Re: Support UUIDv6 in uuid_extract_timestamp()

От:
Masahiko Sawada <sawada.mshk@gmail.com>
Дата:
On Mon, Aug 3, 2026 at 3:53 PM Masahiko Sawada  wrote:
>
> On Mon, Aug 3, 2026 at 12:55 PM Tristan Partin  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  wrote:
> > >>
> > >> On Wed, Jun 24, 2026 at 1:10 PM Tristan Partin  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

Support UUIDv6 in uuid_extract_timestamp()

От:
"Tristan Partin" <tristan@partin.io>
Дата:
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)

Re: Support UUIDv6 in uuid_extract_timestamp()

От:
"Tristan Partin" <tristan@partin.io>
Дата:
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  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)
FAQ