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. OTOH, that means that we can't
build uuid-ossp on Windows today anyway, so failing to support it
makes things no worse than before ... and anybody who wants that
can always send a patch.
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. (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.)
Whether these are good enough reasons to continue carrying all
that code is unclear to me. Thoughts?
regards, tom lane