Hi,
On 2022-01-08 15:35:33 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-01-08 14:59:56 -0500, Tom Lane wrote:
> >> Right, I was planning to have a look at how they'd done it. The BSD
> >> implementation seems to be inside the kernel, so that's not likely
> >> to be helpful, but the other two must be in userspace.
>
> > https://github.com/tytso/e2fsprogs/blob/master/lib/uuid/gen_uuid.c#L240
> > https://github.com/sean-/ossp-uuid/blob/master/uuid_mac.c#L92
>
> Thanks for the pointers! I was hoping for a Windows version, but
> neither one seems to cover that.
e2fs does have something, in a separate file:
https://github.com/tytso/e2fsprogs/blob/master/lib/uuid/gen_uuid_nt.c
but it looks pretty ugly. But it seems like it'd not be too hard to just use
UuidCreateSequential() or UuidCreate() on windows.
https://docs.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidcreate
> Before I start writing code, there seem to be two possible approaches
> here:
>
> 1. Rip out all the external-library dependencies, lock stock and
> barrel. contrib/uuid-ossp is always built. --with-uuid configure
> argument becomes a no-op or an error.
>
> 2. contrib/uuid-ossp is always built, but if you say --with-uuid
> then the existing code for that library is used. We fall back to
> homegrown code if you didn't say --with-uuid.
>
> The main argument for #2 would be to preserve bug compatibility with
> the existing behavior, in case (say) we pick a different interface's
> MAC address than you got before. I suppose also it's possible that
> the existing libraries try harder to avoid collisions across UUIDs
> generated in different processes than I envision doing in our own
> version.
>
> Whether these are good enough reasons to continue carrying all
> that code is unclear to me. Thoughts?
I'm inclined to think that we shouldn't carry that much code just for some
pretty tenuous backward compatibility reasons.
I wonder if we shouldn't just move all the uuid stuff to core, and make
uuid-ossp be an empty shell for a few releases. It's already pretty
confusingly named, with awkward quoting etc. In a few years it'll be
completely unintelligible.
> (I think v1 UUID uniqueness is snake-oil anyway, so I'm just thinking of
> choosing a random "clock sequence" in each process and calling it good.)
Hm. Not so sure about that... If we go there, why don't we just rip out the
ability to create v1 UUIDs?
Greetings,
Andres Freund