public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrey Borodin <[email protected]>
To: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Sergey Prokhorenko <[email protected]>
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
Date: Thu, 23 Oct 2025 18:06:43 +0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CAJ7c6TOramr1UTLcyB128LWMqita1Y7=arq3KHaU=qikf5yKOQ@mail.gmail.com>

Hello!

> On 23 Oct 2025, at 14:55, Aleksander Alekseev <[email protected]> wrote:
> 
> 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:
> 
> 1. Implement uuid -> bytea and bytea -> uuid casting
> 2. Implement encode(bytea, 'base32') and decode(text, 'base32')
> 
> So the overall interface should be like this:
> 
> 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.

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]
  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