> > 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. >
Hi there, Firstly, I'd like to discuss the increased_clock_precision variable, which currently divides the timestamp into milliseconds and nanoseconds. However, this approach only approximates the extra bits for sub-millisecond precision, leading to imprecise timestamps in high-frequency UUID generation. To address this issue, we could consider using a more accurate method for calculating the timestamp. For instance, we could utilize a higher resolution clock or implement a more precise algorithm to ensure accurate timestamps. Additionally, it would be beneficial to add validation checks for the interval argument. These checks could verify that the input interval is within reasonable bounds and that the calculated timestamp is accurate. Examples of checks could include verifying if the interval is too small, too large, or exceeds the maximum possible number of milliseconds and nanoseconds in a timestamp. By implementing these changes, we can improve the accuracy and reliability of UUID generation, making it more suitable for high-frequency usage scenarios. What do you think about these suggestions? Let me know your thoughts! Best Regards, Stepan Neretin!
