On Fri, Oct 24, 2025 at 12:17 AM Sergey Prokhorenko
<[email protected]> wrote:
>
>
> Masahiko,
>
> Developers will still be able to use the long canonical 'hex' UUID format for
> compatibility. But the short format is not a developer choice, but a
> convention. We mustn't allow a situation where 25% of systems use base32hex,
> 25% use Crocksford's Base32, 25% use base36, and 25% even use erroneously
> sorted base64. That's a very real nightmare. You, too, have every reason not
> to want to increase the number of built-in functions in PostgreSQL.
>
> But here is a solution that I hope will satisfy everyone:
>
> encode('019535d9-3df7-79fb-b466-fa907fa17f9e', 'uuid_to_base32hex') ->
> 06AJBM9TUTSVND36VA87V8BVJO
Does it mean the first argument is uuid type data and when
'uuid_to_base32hex' is specified as the format the function requires a
uuid data at the first argument? I could not understand the difference
between specifying 'based32hex' and 'uuid_to_base32hex' when encoding
UUID data with base32hex encoding.
> decode('06AJBM9TUTSVND36VA87V8BVJO', 'base32hex_to_uuid') ->
> 019535d9-3df7-79fb-b466-fa907fa17f9e
Suppose that the decode() takes text data at the first argument and
returns UUID data, the function signature would be decode(text, text)
-> uuid. But we cannot create two functions that have the same name
and the same argument types.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
