Re: UUID v7
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter@eisentraut.org>, Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>, 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-03-12T06:31:48Z
Lists: pgsql-hackers
On Tue, Mar 12, 2024 at 11:10:37AM +0500, Andrey M. Borodin wrote: > On 12 Mar 2024, at 10:53, Michael Paquier <michael@paquier.xyz> wrote: >> On 22 Jan 2024, at 09:22, Nikolay Samokhvalov <nik@postgres.ai> wrote: >> >> And many libraries are already including implementation of UUIDv7 – here are some examples: >> >> - https://www.npmjs.com/package/uuidv7 >> - https://crates.io/crates/uuidv7 >> - https://github.com/google/uuid/pull/139 > > So at least reviewing patch and agreeing on chosen methods and constants makes sense. Sure, there is no problem in discussing a patch to implement a behavior. But I disagree about taking a risk in merging something that could become non-compliant with the approved RFC, if the draft is approved at the end, of course. This just strikes me as a bad idea. -- Michael
Commits
-
Fix timestamp overflow in UUIDv7 implementation.
- a5419bc72e22 18.0 landed
-
Add UUID version 7 generation function.
- 78c5e141e9c1 18.0 landed
-
Add some UUID support functions
- 794f10f6b920 17.0 landed