> On 14 Mar 2024, at 16:07, Peter Eisentraut <pe...@eisentraut.org> wrote:
>
> On 10.03.24 13:59, Andrey M. Borodin wrote:
>>> The functions uuid_extract_ver and uuid_extract_var could be named
>>> uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
>>> to tell them apart, with only one letter different.
>> Renamed.
>
> Another related comment: Throughout your patch, swap the order of
> uuid_extract_variant and uuid_extract_version. First, this makes more sense
> because version is subordinate to variant, and also it makes it alphabetical.
I will do it soon.
>
>>> I think the behavior of uuid_extract_var(iant) is wrong. The code
>>> takes just two bits to return, but the draft document is quite clear
>>> that the variant is 4 bits (see Table 1).
>> Well, it was correct only for implemented variant. I've made version that
>> implements full table 1 from section 4.1.
>
> I think we are still interpreting this differently. I think
> uuid_extract_variant should just return whatever is in those four bits. Your
> function comment says "Can return only 0, 0b10, 0b110 and 0b111.", which I
> don't think it is correct. It should return 0 through 15.
We will return "do not care" bits. This bits can confuse someone. E.g. for
varaint 0b10 we can return 8, 9, 10 and 11 randomly. Is it OK? BTW for some
reason document lists number 1-15, but your are correct that range is 0-15.
>
>>> I would have expected that, since gettimeofday() provides microsecond
>>> precision, we'd put the extra precision into "rand_a" as per Section 6.2
>>> method 3.
>> I had chosen method 2 over method 3 as most portable. Can we be sure how
>> many bits (after reading milliseconds) are there across different OSes?
>
> I think this should have been researched. If we don't know how many bits we
> have, how do we know we have enough for milliseconds? I think we should at
> least have some kind of idea, if we are going to have this conversation.
Bits for milliseconds are strictly defined by the document: there are always 48
bits, independently from clock resolution.
But I don't think it's main problem for Method 3. Method 1 actually guarantees
strictly increasing order of UUIDs generated by single backend. Method 3 can
generate a lot of unsorted data in case of time leaping backward.
BTW Kyzer (in an off-list discussion) and Sergey confirmed that implemented
method from the patch actually is Method 1.
Best regards, Andrey Borodin.
