Horton

Re: UUID v7

x4mmm@yandex-team.ru

View thread View on postgr.es
From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, Jelte Fennema-Nio <postgres@jeltef.nl>, Michael Paquier <michael@paquier.xyz>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter@eisentraut.org>, Przemysław Sztoch <przemyslaw@sztoch.pl>, "David G. Johnston" <david.g.johnston@gmail.com>, Mat Arye <mat@timescaledb.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Nikolay Samokhvalov <samokhvalov@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>
Date: 2024-10-31T18:45:49Z
Lists: pgsql-hackers

Attachments


> On 31 Oct 2024, at 22:15, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 
> On Sat, Oct 26, 2024 at 10:05 AM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
> 
> I think we typically avoid this kind of check failure by assigning
> uuidv7() and uuidv7(interval) different C functions that call the
> common function. That is, we have pg_proc entries like:
> 

Done.

>>> 
>>> It's odd to me that only uuid_extract_timestamp() supports UUID v6 in
>>> spite of not supporting UUID v6 generation. I think it makes more
>>> sense to support UUID v6 generation as well, if the need for it is
>>> high.
>> 
>> RFC urges to use UUIDv7 instead of UUIDv6 when possible. I'm fine with providing implementation, it's trivial. PFA patch with implementation.
>> 
> 
> My point is that we should either support full functionality for
> UUIDv6 (such as generation and extraction) or none of them. I'm not
> really sure we want UUIDv6 as well, but if we want it, it should be
> implemented in a separate patch.

Make sense. I've removed all traces of v6.

Thanks!


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