Gevik, >uniqueness is never a guaranteed. that is according to the RFC docs.
>uniqueness is never a guaranteed in the sense that there is a tiny >chance someone of the other side of the planet might generate the same >guid.
As much as I learned, it is recommended to give information about "grade of uniqueness". I think it would be a valuable information, which information your UUID-generator takes into account, and what the "grade of uniqueness" is.
(I know of the Windows UUID, which takes the MAC-Address of the included Ethernet-Card into it's calculation, which may be guaranteed to be unique)
Some more questions about UUIDs and your patch:
a) compatibility of UUIDs -> I have generated a lot of UUIDs via the WIN32 provided function (for the unix-only-people: Windows uses UUIDs all around its registry, software IDs and on and on). How unique are those UUIDs when mixed with "your" UUIDs ?
b) I read some time ago about the problems with UUIDs as primary keys in contrast to serials: serials get produced in ascending order; and often data which was produced in one timespan is also connected semantically. "near serial values" are also local within a btree-index; but UUIDs generated in "near times" are usually spread around the possible bitranges. (example for sequence of serials: 1 - 2 - 3 - 4 - 5 - 6 example for sequence of UUIDs : 1 - 999919281921843191 - 782 - 18291831912318971231) that is supposed to affect the locality of the index, and from that also the performance of the system.
I do not know how valid this information is; so I am asking you for your feedback; especially since you put a lot of thoughts into this UUID patch. Maybe you took allready care of this situation when constructing the index operators?
Thanks
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.