> I'd still prefer to see a native 16-byte UUID type.
> I'm not wild about the "privacy" aspects associated
> with UUIDs generated the "old style."

I agree with all this and more.

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
UUID fields.

-- 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
bothers you.

We dont even need 16-byte (or 32-byte) arithmetic
in the server codebase.

So, why is this resistance? Anyone care to explain?

Cheers,
Adem