|Subject||Re: UUID sidetracks|
> I'd still prefer to see a native 16-byte UUID type.I agree with all this and more.
> I'm not wild about the "privacy" aspects associated
> with UUIDs generated the "old style."
I will settle for a plain 16-byte data type (i.e. Firebird
does not have to have autogenerated fields),
There are so many reasons I need this:
-- any GUID I generate in my own app travels over the
net as 16-byte and not as 36-char string.
-- Similarly, there is a reduction in database size
which can be significant if you use a lot of
-- Indexing and seeking etc. would be faster
-- I can deal with UUID data type directly in my
app, I really do not need the overhead of
convertin to and from string type.
All in all, I have never really understood the
architect people's resistance to let us have 16-byte
(hell, even 32-byte) indexable fields.
We dont have to call them UUID fields if that
We dont even need 16-byte (or 32-byte) arithmetic
in the server codebase.
So, why is this resistance? Anyone care to explain?