Horton

Re: UUID v7

x4mmm@yandex-team.ru

View thread View on postgr.es
From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, 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-30T09:56:10Z
Lists: pgsql-hackers

Attachments


> On 30 Jan 2024, at 12:28, Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au> wrote:
> 
> 
> I think this phrase is outdated: "This function can optionally accept a timestamp used instead of current time.
> This allows implementation of k-way sotable identifiers.”
Fixed.

> This phrase is wrong: "Both functions return a version 4 (random) UUID.”
This applies to functions gen_random_uuid() and uuidv4().
> 
> For this phrase the reason is unclear and the phrase is most likely incorrect:
> if large batches of UUIDs are generated at the
> +   same time it's possible that some UUIDs will store a time that is slightly later
> +   than their actual generation time

I’ve rewritten this phrase, hope it’s more clear now.


Best regards, Andrey Borodin.

Commits

  1. Fix timestamp overflow in UUIDv7 implementation.

  2. Add UUID version 7 generation function.

  3. Add some UUID support functions