I have run into a scenario where a customer may have a nullable guid for me to compare to in my database. I could go ahead and rewrite my call stack to make the object nullable, but I also don't want to do that. I'm considering just doing a null check at the data ingestion point and coalescing to 00000000-0000-0000-0000-000000000000, but am not sure if that's "safe" as I'm not sure if a guid generator could actually generate that guid randomly
(yes, I know that I could pick any random guid and the odds of a guid generator picking it are stupidly low, but I'm really more curious if the 0-value guid is reserved)
TL;DR it is safe to use
COALESCE(MyGUID, '00000000-0000-0000-0000-000000000000').I did some research and, as best I can determine, it IS theoretically possible to generate this value since it is obtained by all the bits being set to
0.However, according to RFC4122 the way its constructed means this will never happen (some bits are added to help with the uniqueness).
The RFC also specifically refers to the "NIL GUID", though it doesn't mention whether this is reserved or whether it will ever be hit.
Even if the total number of possible GUIDs were possible, this is 2^212.
So the chances of getting that particular value is 1 in 5,316,911,983,139,663,491,615,228,241,121,400,000 !
For comparison the chances of a collision are 1 in 1,000,000,000.
And while the probability that a UUID collision will occur is not zero, it is generally considered so close to zero as to be negligible.
Lastly many languages use the value as a nil GUID i.e. it is reserved e.g. C#'s
Guid.Empty.So I surmise that it is safe to use in a coalesce in any language as long as you are using generated GUIDs (i.e. you don't have a someone or something that could manually set / pass in / insert a nil GUID value).