Feedback-ID: i1ff147bf:Fastmail
From: =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org>
To: Aleksander Alekseev <aleksander@tigerdata.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,  Jelte Fennema-Nio
 <postgres@jeltef.nl>,  Sergey Prokhorenko
 <sergeyprokhorenko@yahoo.com.au>,  Andrey Borodin <x4mmm@yandex-team.ru>,
  Masahiko Sawada <sawada.mshk@gmail.com>
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in
 functions
References: <1791665551.452444.1761209220211.ref@mail.yahoo.com>
	<1791665551.452444.1761209220211@mail.yahoo.com>
	<CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>
	<18022523-0F8F-4C07-AFF5-57DC9086D78E@yandex-team.ru>
	<1895971769.8343.1761240853939@mail.yahoo.com>
	<CAD21AoCxy_3VW2_z5Rxc-tFsuqeyGsA-F_kD-tx6XXBC56nTCg@mail.gmail.com>
	<574624399.175025.1761290201491@mail.yahoo.com>
	<CAD21AoAXQcZ2mMkxX6NPdFpdC-D3AhE--qyH9Se3XTrDX6x-bg@mail.gmail.com>
	<953203149.383019.1761345585325@mail.yahoo.com>
	<CAD21AoCzEDdwpyPwA0d-QmCRe5rMz3m160SJgxMwKke85e8n0w@mail.gmail.com>
	<6F76FA61-E2DC-44EF-9504-889D9BDB4EBD@yandex-team.ru>
	<CAD21AoCKvYCccndY4CRcwk1bOuWxJionOidEtKQWoJTqS7wL1g@mail.gmail.com>
	<1154454839.957923.1761604611424@mail.yahoo.com>
	<CAGECzQTb9pg2Qw0XmOEKaJivLJ8kdGq3Cq38OqSgwiFVD=9f8A@mail.gmail.com>
	<87ldkv8cog.fsf@wibble.ilmari.org> <87ikfz7zcu.fsf@wibble.ilmari.org>
	<CAGECzQTEK58Ef8w5xA=8KGT6D2seHF0fN0XNdgRov7Lp4bitGQ@mail.gmail.com>
	<87frb27zg3.fsf@wibble.ilmari.org>
	<CAJ7c6TOpO7tL87fBpFEn6DQRfGzT8NQiNtDzE2XrhJQ0-FOmuA@mail.gmail.com>
Date: Wed, 29 Oct 2025 12:04:24 +0000
In-Reply-To: 
 <CAJ7c6TOpO7tL87fBpFEn6DQRfGzT8NQiNtDzE2XrhJQ0-FOmuA@mail.gmail.com>
	(Aleksander Alekseev's message of "Wed, 29 Oct 2025 14:31:29 +0300")
Message-ID: <87cy659anr.fsf@wibble.ilmari.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/87cy659anr.fsf%40wibble.ilmari.org>
Precedence: bulk

Aleksander Alekseev <aleksander@tigerdata.com> 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