Horton

Re: UUID v7

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread View on postgr.es
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Aleksander Alekseev <aleksander@timescale.com>, Przemysław Sztoch <przemyslaw@sztoch.pl>, Nikolay Samokhvalov <nik@postgres.ai>, "David G. Johnston" <david.g.johnston@gmail.com>, Nick Babadzhanian <pgnickb@gmail.com>, Mat Arye <mat@timescaledb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Daniel Gustafsson <daniel@yesql.se>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Nikolay Samokhvalov <samokhvalov@gmail.com>, "Kyzer Davis (kydavis)" <kydavis@cisco.com>, Andres Freund <andres@anarazel.de>, "brad@peabody.io" <brad@peabody.io>, Kirk Wolak <wolakk@gmail.com>
Date: 2024-01-29T20:38:27Z
Lists: pgsql-hackers 
On Mon, 29 Jan 2024 at 19:32, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
> Even if the developer pass constant time to uuidv7(T) they will get what they asked for - unique identifier. Moreover - it still will be keeping locality. There will be no negative consequences at all.

It will be significantly "less unique" than if they wouldn't pass a
constant time. Basically it would become a UUIDv4, but with 74 bits of
random data instead of 122. That might not be enough anymore to
"guarantee" uniqueness. I guess that's why it is required to use
UUIDv8 in these cases, because correct usage is now a requirement for
assuming uniqueness. And for UUIDv8 the spec says this:

> UUIDv8's uniqueness will be implementation-specific and MUST NOT be assumed.

> > On 29 Jan 2024, at 18:58, Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > If other timestamp sources or
> > a custom timestamp epoch are required, UUIDv8 MUST be used.
>
> Well, yeah. RFC says this... in 4 capital letters :)

As an FYI, there is an RFC that defines these keywords that's why they
are capital letters: https://www.ietf.org/rfc/rfc2119.txt

> I believe it's kind of a big deficiency that k-way sortable identifiers are not implementable on top of UUIDv7. Well, let's go without this function. UUIDv7 is still an improvement over previous versions.

Yeah, I liked the feature to generate UUIDv7 based on timestamp too.
But following the spec seems more important than a nice feature to me.

Commits

  1. Fix timestamp overflow in UUIDv7 implementation.

  2. Add UUID version 7 generation function.

  3. Add some UUID support functions