All,
CORE-3238 is the problem related to UUIDs version and reserved bytes
which we're not respecting.
Note that in Windows, we generate UUIDs with a WinAPI function so it
generates correct numbers, but in POSIX we just generate random data.
1) So from a POV, we may say our GEN_UUID is correct in Windows only,
and that UUID_TO_CHAR (and CHAR_TO_UUID) are always incorrect, since
they don't put each reserved byte in the correct text representation place.
In this POV, we may need to change POSIX GEN_UUID and introduce new
functions for TO/FROM CHAR.
2) I'd instead would consider another way. I'd say current GEN_UUID is
always wrong, and just change it for all platforms.
The new version will translate the Windows GUID differently, so the
reserved bytes would be in the right place for FROM/TO CHAR functions
work correctly.
In this way we also maintain the below property, where the string
representation matches the octet one:
execute block returns (
o varchar(16) character set octets,
c varchar(36)
)
as
begin
o = gen_uuid();
c = uuid_to_char(o);
suspend;
end!
O C
================================ ====================================
45FF45D9D376B9674BEBC55841BD0E2F 45FF45D9-D376-B967-4BEB-C55841BD0E2F
I also consider better to say it's currently incorrect for Windows too,
since UUIDs nature is to be distributed and may be interchangeable with
ones generated in others platforms.
Comments?
Adriano
------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
