proposal: uuid: add API to generate and parse UUID

[mzattahri]

I would like to suggest the addition to the standard library of a package to generate and parse UUID identifiers, specifically versions 3, 4 and 5.

The main reason I see to include it is that the most popular 3rd-party package (github.com/google/uuid) is a staple import in every server/db based Go program, as confirmed by a quick Github code search.

Additionally:

• UUID is a standard;
• The interface exposed by github.com/google/uuid has been stable for years.

Addendum

Would like to point out how Go is rather the exception than the norm with regards to including UUID support in its standard library.

• C#
• Java
• JavaScript
• Python
• Ruby

[ALTree]

Note that this has been asked -and rejected- in the past, here: #23789, and here #28324.

It's not clear what concrete, tangible benefits would bringing github.com/google/uuid in the standard library give us. Third-party packages are easy to import and use, and can have a more flexible release cycle than the standard library.

[mzattahri]

Guess the strongest argument is going to be that if you have to import it externally every time, it might as well be part of the standard library in the first place.

Pretty much every other language does, and tends to include it as part of its crypto library.

[sergeyprokhorenko]

UUID versions 1, 2, 3, 4, 5 are already outdated. The latest and most promising version is 7. See https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/ However, version 7 allows for many different implementation options. It is necessary to wait for the results of applying various options.

6.12. Opacity
As general guidance, it is recommend to avoid parsing UUID values unnecessarily, and instead treating UUIDs as opaquely as possible. Although application-specific concerns could of course require some degree of introspection (e.g., to examine the Section 4.1, Section 4.2 or perhaps the timestamp of a UUID), the advice here is to avoid this or other parsing unless absolutely necessary. Applications typically tend to be simpler, more interoperable, and perform better, when this advice is followed.
Sourse: https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-14.html#name-opacity

[hu3bi]

The RFC https://www.rfc-editor.org/rfc/rfc9562.html is now published and no longer in draft.

Is there any chance we can get a decision about this proposal?
Postgres 18 also added uuidv7 support.

[sergeyprokhorenko]

The implementation of uuidv7() for PostgreSQL 18 is perfect

[seankhliao]

As an alternative, we're proposing only handling UUID generation.
Parsing is left out of scope, in line with the RFC's recommendation to treat them as opaque identifers.

#76319

[mzattahri]

Guess this is a dupe then.