Re: UUID v7
От | Aleksander Alekseev |
---|---|
Тема | Re: UUID v7 |
Дата | |
Msg-id | CAJ7c6TPvmkffDGO6ma2AGs8DUAMnOc+YYVnN=O5LLuQ-rbzLdg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: UUID v7 (Nikolay Samokhvalov <nik@postgres.ai>) |
Ответы |
Re: UUID v7
(Aleksander Alekseev <aleksander@timescale.com>)
|
Список | pgsql-hackers |
Hi, > But now (after big timeseries project with multiple time zones and DST problems) I think differently. > Even though timestamp and timestamptz are practically the same, timestamptz should be used to store the time in UTC. > Choosing timestamp is more likely to lead to problems and misunderstandings than timestamptz. As somebody who contributed TZ support to TimescaleDB I'm more or less aware about the pros and cons of Timestamp and TimestampTz :) Engineering is all about compromises. I can imagine a project where it makes sense to use only TimestampTz for the entire database, and the opposite - when it's better to use only UTC and Timestamp. In this particular case I was merely concerned that the particular choice could be confusing for the users but I think I changed my mind by now, see below. >> Here's v12. Changes: >> 1. Documentation improvements >> 2. Code comments >> 3. Better commit message and reviews list > > > Thank you, Andrey! I have just checked v12 – cleanly applied to HEAD, and functions work well. I especially like that factthat we keep uuid_extract_time(..) here – this is a great thing to have for time-based partitioning, and in many caseswe will be able to decide not to have a creation column timestamp (e.g., "created_at") at all, saving 8 bytes. > > The docs and comments look great too. > > Overall, the patch looks mature enough. It would be great to have it in pg17. Yes, the RFC is not fully finalized yet,but it's very close. 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 Thanks! After playing with v12 I'm inclined to agree that it's RfC. I only have a couple of silly nitpicks: - It could make sense to decompose the C implementation of uuidv7() in two functions, for readability. - It could make sense to get rid of curly braces in SQL tests when calling uuid_extract_ver() and uuid_extract_ver(), for consistency. I'm not going to insist on these changes though and prefer leaving it to the author and the committer to decide. Also I take back what I said above about using Timestamp instead of TimestampTz. I forgot that Timestamps are implicitly casted to TimestampTz's, so users preferring Timestamps can do this: ``` =# select uuidv7('2024-01-22 12:34:56' :: timestamp); uuidv7 -------------------------------------- 018d3085-de00-77c1-9e7b-7b04ddb9ebb9 ``` Cfbot also seems to be happy with the patch so I'm changing the CF entry status to RfC. -- Best regards, Aleksander Alekseev
В списке pgsql-hackers по дате отправления: