On Thu, Oct 31, 2024 at 11:46 AM Andrey M. Borodin <x4...@yandex-team.ru> wrote: > > > > > On 31 Oct 2024, at 22:15, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > On Sat, Oct 26, 2024 at 10:05 AM Andrey M. Borodin <x4...@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.
Thank you for updating the patch. I've been studying UUID v7 and have a question about the current (v29) implementation. IIUC the current implementation uses nanosecond-precision timestamps for both the first 48 bit space and 12 bits of pseudorandom data space (referred as 'rand_a' space in RFC 9562). IOW, all data except for random, version, and variant parts consist of a timestamp. The nanosecond-precision timestamp is generated using clock_gettime() with CLOCK_REALTIME on Linux, which however could be affected by time adjustment by NTP. Therefore, if the system clock moves backward due to NTP, we cannot guarantee monotonicity and sortability. Is that right? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
