From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Andy Alsup <bluesbreaker(at)gmail(dot)com> |
Cc: | Pgsql-Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Update docs for UUID data type |
Date: | 2025-02-25 17:41:48 |
Message-ID: | 44cd5f161882394ee23483ee76b3ebfa0c942cfe.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2025-02-24 at 21:04 -0500, Andy Alsup wrote:
> Please find the attached patch, which only addresses the UUID functions
> (in table format). I appreciate the comments related to the UUID datatype.
> If you feel like the additional content didn't add clarity, I certainly won't argue.
Your patch looks good to me.
I didn't mean that adding more information about the "uuid" data type is
a bad thing. Perhaps that additional paragraph could be
RFC 9562 defines 8 different UUID versions. Each version has specific requirements
for generating new UUID values, and each version provides distinct benefits and drawbacks.
<productname>PostgreSQL</productname> provides native support for generating UUIDs
using the UUIDv4 and UUIDv7 algorithms. Alternatively, UUID values can be generated
outside of the database using any algorithm. The data type <type>uuid</type> can be used
to store any UUID, regardless of the origin and the UUID version.
I would be happy if you added something like that again.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-02-25 17:44:42 | Re: Redact user password on pg_stat_statements |
Previous Message | Tomas Vondra | 2025-02-25 17:39:09 | Re: Adjusting hash join memory limit to handle batch explosion |