public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dagfinn Ilmari Mannsåker <[email protected]>
To: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Sergey Prokhorenko <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
Date: Wed, 29 Oct 2025 12:04:24 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJ7c6TOpO7tL87fBpFEn6DQRfGzT8NQiNtDzE2XrhJQ0-FOmuA@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAD21AoCxy_3VW2_z5Rxc-tFsuqeyGsA-F_kD-tx6XXBC56nTCg@mail.gmail.com>
<[email protected]>
<CAD21AoAXQcZ2mMkxX6NPdFpdC-D3AhE--qyH9Se3XTrDX6x-bg@mail.gmail.com>
<[email protected]>
<CAD21AoCzEDdwpyPwA0d-QmCRe5rMz3m160SJgxMwKke85e8n0w@mail.gmail.com>
<[email protected]>
<CAD21AoCKvYCccndY4CRcwk1bOuWxJionOidEtKQWoJTqS7wL1g@mail.gmail.com>
<[email protected]>
<CAGECzQTb9pg2Qw0XmOEKaJivLJ8kdGq3Cq38OqSgwiFVD=9f8A@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAGECzQTEK58Ef8w5xA=8KGT6D2seHF0fN0XNdgRov7Lp4bitGQ@mail.gmail.com>
<[email protected]>
<CAJ7c6TOpO7tL87fBpFEn6DQRfGzT8NQiNtDzE2XrhJQ0-FOmuA@mail.gmail.com>
Aleksander Alekseev <[email protected]> writes:
> Hi,
>
> Thanks for the patch.
>
>> That does seem like a better fit. It's used mainly in recv functions,
>> which this basically is (but user-callable).
>>
>> Updated patch attaced.
>
> Perhaps bytea_uuid() should check the UUID format. Consider the
> following example:
>
> SELECT uuid_extract_version('\x019a2f859cedffffb99d9c55044a2563'::bytea::uuid);
> uuid_extract_version
> ----------------------
> 15
The UUID input function doesn't do any such validation, so I don't see
why the cast should behave any differently:
# select '019a2f859cedffffb99d9c55044a2563'::uuid;
┌──────────────────────────────────────┐
│ uuid │
├──────────────────────────────────────┤
│ 019a2f85-9ced-ffff-b99d-9c55044a2563 │
└──────────────────────────────────────┘
# select uuid_extract_version('019a2f859cedffffb99d9c55044a2563'::uuid);
┌──────────────────────┐
│ uuid_extract_version │
├──────────────────────┤
│ 15 │
└──────────────────────┘
(1 row)
> There is no UUID version 15 according to RFC 9562, and the
> documentation for uuid_extract_version() says:
There's no version 15 specified _yet_.
> """
> Extracts the version from a UUID of the variant described by RFC 9562.
> For other variants, this function returns null. For example, for a
> UUID generated by gen_random_uuid, this function will return 4.
> """
>
> If I read this correctly, either bytea_uuid() should reject this, or
> uuid_extract_version() should be modified to return NULL, or the
> documentation for uuid_extract_version() should be altered.
Future RFCs could define new versions of this variant, which we should
not reject or pretend don't have a version , just because we haven't
heard of them yet. In fact, RFC 9562 defines two new versions, v7 and
v8, which by this argument PostgreSQL versions before 18 should reject.
- ilmari
view thread (62+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox