| 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: | Whole Thread | Raw Message | 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 |