Hello!
> On 23 Oct 2025, at 14:55, Aleksander Alekseev <aleksander@tigerdata.com> 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-friendlythan default (123e4567-e89b-12d3-a456-426614174000). But why should we bother with propagating one
dataformat 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,
extendreasoning 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.
