Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in
 functions
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: 
 <CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>
Date: Thu, 23 Oct 2025 18:06:43 +0500
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
 Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>
Content-Transfer-Encoding: quoted-printable
Message-Id: <18022523-0F8F-4C07-AFF5-57DC9086D78E@yandex-team.ru>
References: <1791665551.452444.1761209220211.ref@mail.yahoo.com>
 <1791665551.452444.1761209220211@mail.yahoo.com>
 <CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>
To: Aleksander Alekseev <aleksander@tigerdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/18022523-0F8F-4C07-AFF5-57DC9086D78E%40yandex-team.ru>
Precedence: bulk

Hello!

> On 23 Oct 2025, at 14:55, Aleksander Alekseev =
<aleksander@tigerdata.com> wrote:
>=20
> Secondly, in order to propose a patch please use `git format-patch`
> and send it as an attachment. Then register it on the nearest open
> commitfest [1].

I think it's not about review yet, but more of a discussing viability =
and general approach.
The code itself is trivial in this case.

My first reaction was very skeptical too. Yes, this representation =
(28V4APV8JC9D792M89J185Q000) seems more developer-friendly than default =
(123e4567-e89b-12d3-a456-426614174000). But why should we bother with =
propagating one data format over another?

Yet, this format is RFC-blessed. It makes sense to consider providing an =
alternative to unfriendly format.

> The interface you are proposing is ugly and is not composable. The
> right way of doing this IMO would be:
>=20
> 1. Implement uuid -> bytea and bytea -> uuid casting
> 2. Implement encode(bytea, 'base32') and decode(text, 'base32')
>=20
> So the overall interface should be like this:
>=20
> SELECT encode(uuidv7() :: bytea, 'base32');

That's an excellent feedback! Would such conversion be idiomatic for =
Postgres users?
Are there any other alternative approaches?

> The value of converting uuid to base32 is not obvious though, so I
> would recommend explaining it in more detail.

Yes, and maybe some examples of other systems that adopted this format =
would be handy too. Sergey, can you, please, extend reasoning why this =
particular format is prominent? RFC 4648 describes a bunch of formats.

> Consider starting a new
> thread for each separate patch.

I think this thread is fine for discussing.

Thank you!


Best regards, Andrey Borodin.=