Using UUIDs - comp.databases.ingres

Message from discussion Using UUIDs

Roy Hann

View profile

More options May 9, 3:44 pm

Newsgroups: comp.databases.ingres

From: "Roy Hann" <specia...@processed.almost.meat>

Date: Fri, 9 May 2008 20:44:07 +0100

Local: Fri, May 9 2008 3:44 pm

Subject: Re: [Info-Ingres] Using UUIDs

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

"Paul Mason" <latep...@gmail.com> wrote in message

news:mailman.215.1210358563.2607.info-ingres@kettleriverconsulting.com...

> 2008/5/9 Roy Hann <specia...@processed.almost.meat>:

>> I am looking at using uuid_create() to generate UUIDs. The SQL
>> Reference Manual talks about the internal structure of the UUIDs
>> generated but I am extremely unclear about whether the value actually
>> returned can be parsed as described.

> They can, though I'm not sure why you'd want to.

I was hoping to sort on the time stamp components to recover the order in
which a set of rows were originally created.

> I have come across a
> couple of bugs in early 2.6 days with UUIDs, however since they were
> fixed (may 2005) the format is as described.

>> I do know UUIDs come in different "versions", including hashed and
>> randomized.

>> What version is Ingres going to give me?
> Not sure about that. The only "random" element is based on the
> timestamp.

Since I posted this question a careful reading of
http://www.ietf.org/rfc/rfc4122.txt tells me that UUIDs returned by
uuid_to_char() that look like these below, generated using II 9.1.0
(int.w32/119):

bb15cc31-fcc9-4c6e-ad21-7349e11f5e14
8f98246f-e393-44e5-9d9c-718838e89f93
70e9e3dc-7f3c-436c-a913-f03279d4f28d
2cd1136c-0e2b-423c-9253-b461d29d7755

are Version 4 (because the high-order 4 bits of the so-called
"time_hi_and_version" field are 0100).

If these are version 4 UUIDs then every other bit is supposed to be randomly
generated (per the RFC document) and are nothing to do with timestamps or
node names or anything else that the SQL Reference Manual documents.
Clearly the values above are all over the place--most obviously the node
part is definitely not constant.

>> Is there any sensible interpretation of the output of uuid_to_char()?
> I'd suggest taking a look at the source
> (http://code.ingres.com/ingres/main/src/cl/clf/id_unix/iduuid.c or
> http://code.ingres.com/ingres/main/src/cl/clf/id_win/iduuid.c) It's
> pretty heavily commented

I did. The id_win version is pretty much commented out. But even more
mysteriously, the id_unix version does all kinds of whirling and clanking to
produce a UUID based on time and node, and sets the version number using

#ifdef BYTE_SWAP
version = 0x1000;
#else
version = 0x0010;

neither of which is 4. So I wonder, is the source we see the source for
what we're executing?

Roy

Reply to author Forward