Re: UUID v7

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Andrew Alsup <bluesbreaker(at)gmail(dot)com>
Cc: Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, Michael Paquier <michael(at)paquier(dot)xyz>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Pgsql-Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, Mat Arye <mat(at)timescaledb(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Stepan Neretin <sncfmgg(at)gmail(dot)com>
Subject: Re: UUID v7
Date: 2025-02-17 02:14:11
Message-ID: CAKFQuwY=WYopLGFvxyDUygQnerdHpBAyGA_zjU2iCFNbj70d3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 16, 2025 at 6:21 PM Andrew Alsup <bluesbreaker(at)gmail(dot)com> wrote:

> Sergey,
>
> I took a look at your patch for chapter 9.14 "UUID Functions" docs page.
> You've added some really good content here. I think section 9.14.4.
> "Deciding Whether and Which UUID to Use" would be better suited for Chapter
> 8: "Data Types" -- specifically, 8.12. "UUID Type", since the content seems
> to deal more with the UUID data type than the UUID functions.
>

Any chance we can bring some organization to this work? The subject line
is too vague to be helpful and thus the thread itself seems to be torn
between fixing stuff in UUID v7 and, separately, making a documentation
enhancement. I don't see a commitfest entry yet - so how about just
starting two new, well-named, threads, with a summary and current patch
proposal for each topic? Though I do sense some overlap such that some of
the content probably needs to be written up assuming the fix patch goes in
first, then the documentation patch. We can always tweak that should the
documentation patch take the lead.

I haven't followed the technical subthread but was asked to comment on the
documentation work off-list (spending enough time editing the DOCX original
and imposing what seems to be the current proposed structure to at least
warrant a mention). A decent part of my commentary was basically that a
lot of this material seems outside the scope of what we cover in our
documentation generally. I'd probably be ok with moving it to an appendix
and making sure the relevant places have links to there. More than just
UUID needs to be altered if you begin comparing UUID to bigint - you need
to add some content to bigint too.

Commenting specifically on the 4 goals:

1. State that from now on, the function uuidv7(), rather than
autoincrement, is the default choice for generating primary keys

We don't make these judgements in the documentation, typically. Happy to
be pointed to exceptions. Simple enough to avoid saying:

"The uuidv7 function is designed as the preferred method for generating
primary keys" and instead just say "...it can be used as an identifier
generator and see Appendix Z for how it compares to other methods."

2. Describe the advantages of uuidv7() over autoincrement and uuidv4()

This is fine; but probably appendix material.

3. Refute the often-cited imaginary disadvantages of UUIDv7 compared to
autoincrement,

This also seems strictly out-of-place; better suited to a Wiki page than
the documentation. Though making statements of fact, and possibly the
occasional clarification of a non-fact, would likely fit inline. Or as
part of the Appendix created to hold the table in goal #2.

4. Confirm the fault tolerance of the uuidv7() function in all possible
critical situations,

This fits into the user-facing specification of the generator function in
some manner.

I did have some alternative text for all this which I'll share, ideally
when there is a clear place to put it up for discussion.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-02-17 02:18:01 Re: BackgroundPsql swallowing errors on windows
Previous Message Tom Lane 2025-02-17 02:01:55 Re: BackgroundPsql swallowing errors on windows