MIME-Version: 1.0
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>
 <1846725727.103615.1761259548268@mail.yahoo.com>
In-Reply-To: <1846725727.103615.1761259548268@mail.yahoo.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Thu, 23 Oct 2025 21:57:55 -0700
Message-ID: 
 <CAD21AoCZbOtExSVCbzy_G4MY9yXREzRTUdXKMxGxdQk41mrauw@mail.gmail.com>
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in
 functions
To: Sergey Prokhorenko <sergeyprokhorenko@yahoo.com.au>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAD21AoCZbOtExSVCbzy_G4MY9yXREzRTUdXKMxGxdQk41mrauw%40mail.gmail.com>
Precedence: bulk

On Thu, Oct 23, 2025 at 3:46=E2=80=AFPM Sergey Prokhorenko
<sergeyprokhorenko@yahoo.com.au> wrote:
>
> > Given that what uuid_to_base32hex() actually does is encoding the
> input UUID,  I find that it could be confusing if we have a similar
> function other than encode() function. Also, we could end up
> introducing as many encoding and decoding functions dedicated for UUID
> as we want to support encoding methods, bloating the functions.
>
> > So as the first step, +1 for supporting base32hex for encode() and
> decode() functions and supporting the UUID <-> bytea conversion. I
> believe it would cover most use cases and the cost of UUID <-> bytea
> conversion is negligible.
>
> > Regards,
>
> > --
> > Masahiko Sawada
> > Amazon Web Services: https://aws.amazon.com
>
>
> Masahiko,
>
> I see you're in favor of base32hex encoding. That's great!
>
> Your arguments make sense, and I generally support enhancing the standard=
 encode() and decode() functions to handle base32hex. It seems like the rig=
ht approach from a developer experience standpoint.
>
> However, I'm unclear about some implementation aspects. Why add conversio=
ns between UUID and bytea data types? Wouldn't that require creating dedica=
ted UUID <-> bytea conversion functions? Instead, could we implement encode=
() as polymorphic to handle UUID type inputs directly? For decode(), we'd n=
eed  some way (a parameter?) to specify the UUID output type instead of byt=
ea. Another option would be automatic type casting when inserting bytea dat=
a into UUID columns. Neither an extra parameter nor additional type casting=
 seems ideal to me, though I don't have better alternatives.

While we can implement something like decode(uuid, text), I don't
think we can implement decode() in the way you proposed unless I'm
missing something.

I think the conversion support between UUID and bytea is useful in
general, not limited to encode()/decode() support. And users would be
able to create wrapper functions if they don't want to add casting for
every encode() and decode() calls. For example,

create function uuid_to_base32(uuid) returns text language sql immutable st=
rict
begin atomic
    select encode($1::bytea, 'base32hex');
end;

Since such functions are inlineable, the different between executing
encode(uuid_data::bytea, 'base32hex') and encode(uuid_data,
'base32hex') would only be the conversion; one palloc and one memcpy.

> But actually, for a short UUID text encoding to succeed, it's more import=
ant that it becomes the single, de facto standard. We should avoid supporti=
ng multiple encodings, just as the authors and contributors of RFC 9562 did=
: https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/discussi=
ons/17#discussioncomment-10614817    Therefore, whenever possible, encode()=
 and decode() should support just one UUID text encoding, namely base32hex.

I guess it's ultimately the developer's choice, no? For example, if
they are using multiple databases (or data processing platforms) in
their system and 'hex' is the only encoding that all components can
encode and decode, they might choose 'hex' encoding.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com