Re: UUID v7 - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: UUID v7
Date
Msg-id 0C26E3AC-983E-43A4-B39E-270FF87A0464@yandex-team.ru
Whole thread Raw
In response to Re: UUID v7  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: UUID v7
List pgsql-hackers

> On 14 Mar 2024, at 20:10, Peter Eisentraut <peter@eisentraut.org> wrote:
>
>>>>> 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
thosefour 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
11randomly. Is it OK? BTW for some reason document lists number 1-15, but your are correct that range is 0-15. 
>
> I agree it's confusing.  Before I studied the RFC 4122bis project, I didn't even know about variant vs. version.  I
thinkoverall people will find this more confusing than useful.  If you just want to know, "is this UUID of the kind
specifiedin RFC 4122", you can query it with uuid_extract_version(x) IS NOT NULL.  So maybe we don't need the
_extract_variantfunction? 

I think it's the best possible solution. The variant has no value besides detecting if a version can be extracted.


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: linux cachestat in file Readv and Prefetch
Next
From: Jeff Davis
Date:
Subject: Re: Pre-proposal: unicode normalized text