| From: | Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au> |
|---|---|
| To: | pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>, Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Cc: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Nick Babadzhanian <pgnickb(at)gmail(dot)com>, Mat Arye <mat(at)timescaledb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, "Kyzer Davis (kydavis)" <kydavis(at)cisco(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "brad(at)peabody(dot)io" <brad(at)peabody(dot)io>, Kirk Wolak <wolakk(at)gmail(dot)com> |
| Subject: | Re: UUID v7 |
| Date: | 2024-01-24 21:30:33 |
| Message-ID: | 2117765841.358258.1706131833031@mail.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Other people" think that extracting the timestamp from UUIDv7 in violation of the new RFC, and generating UUIDv7 from the timestamp were both terrible and poorly thought out ideas. The authors of the new RFC had very good reasons to prohibit this. And the problems you face are the best confirmation of the correctness of the new RFC. It’s better to throw all this gag out of the official patch. Don't tempt developers to break the new RFC with these error-producing functions.
Sergey Prokhorenkosergeyprokhorenko(at)yahoo(dot)com(dot)au
On Wednesday, 24 January 2024 at 04:30:02 pm GMT+3, Aleksander Alekseev <aleksander(at)timescale(dot)com> wrote:
Hi,
> Function to extract timestamp does not provide any guarantees at all. Standard states this, see Kyzer answers upthread.
> Moreover, standard urges against relying on that if uuidX was generated before uuidY, then uuidX<uuid. The standard is doing a lot to make this happen, but does not guaranty that.
> All what is guaranteed is the uniqueness at certain conditions.
>
> > Otherwise you can calculate crc64(X) or sha256(X)
> > internally in order to generate an unique ID and claim that it's fine.
> >
> > Values that violate named invariants should be rejected with an error.
>
> Think about the value that you pass to uuid generation function as an entropy. It’s there to ensure uniqueness and promote ordering (but not guarantee).
If the standard doesn't guarantee something it doesn't mean it forbids
us to give stronger guarantees. I'm convinced that these guarantees
will be useful in real-world applications, at least the ones acting
exclusively within Postgres.
This being said, I understand your point of view too. Let's see what
other people think.
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-01-24 21:32:58 | Re: Patch: Improve Boolean Predicate JSON Path Docs |
| Previous Message | Thomas Munro | 2024-01-24 21:16:02 | Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ] |