Re: [PATCHES] Patch for UUID datatype (beta) - Mailing list pgsql-hackers

From Harald Armin Massa
Subject Re: [PATCHES] Patch for UUID datatype (beta)
Date
Msg-id 7be3f35d0609200002n19af5287r642614ab572f7352@mail.gmail.com
Whole thread Raw
In response to Re: [PATCHES] Patch for UUID datatype (beta)  (mark@mark.mielke.cc)
List pgsql-hackers
Mark,

A model that intended to try and guarantee uniqueness would provide a
UUID generation service for the entire host, that was not specific to
any application, or database, possibly accessible via the loopback
address. It would ensure that at any given time, either the time is
new, or the sequence is new for the time. If computer time ever went
backwards, it could keep the last time issued persistent, and
increment from this point forward through the clock sequence values
until real time catches up. An alternative would be along the lines of
a /dev/uuid device, that like /dev/random, would be responsible for
outputting unique uuid values for the system. Who does this? Probably
nobody. I'm tempted to implement it, though, for my uses. :-)

That is an excellent summary. There is just one wrong assumption in it:

>Probably nobody.

Within win32 there is an API call, which provides you with an GUID / UUID with to my knowledge exactly the features you are describing. win32 is installed on some computers. So for PostgreSQL on win32 the new_guid() you describe in detail would be quite simple to implement: a call to CoCreateGuid.

The challenging part is: I use PostgreSQL in a mixed environment. And Linux i.e. does not provide CoCreateGuid. That's why I am voting to have it in PostgreSQL :)

Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
-
Let's set so double the killer delete select all.

pgsql-hackers by date:

Previous
From: Jeremy Drake
Date:
Subject: Re: polite request about syntax
Next
From: Teodor Sigaev
Date:
Subject: Re: [COMMITTERS] pgsql: Remove completed TODO items: < * -Make postmater