Re: [HACKERS] Patch for UUID datatype (beta)
От | Jim C. Nasby |
---|---|
Тема | Re: [HACKERS] Patch for UUID datatype (beta) |
Дата | |
Msg-id | 20060919141631.GW47167@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Patch for UUID datatype (beta) (mark@mark.mielke.cc) |
Список | pgsql-patches |
On Tue, Sep 19, 2006 at 09:51:23AM -0400, mark@mark.mielke.cc wrote: > On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote: > > On Mon, Sep 18, 2006 at 07:45:07PM -0400, mark@mark.mielke.cc wrote: > > > I would not use a 100% random number generator for a UUID value as was > > > suggested. I prefer inserting the MAC address and the time, to at > > > least allow me to control if a collision is possible. This is not easy > > > to do using a few lines of C code. I'd rather have a UUID type in core > > > with no generation routine, than no UUID type in core because the code > > > is too complicated to maintain, or not portable enough. > > As others have mentioned, using MAC address doesn't remove the > > possibility of a collision. > > It does, as I control the MAC address. I can choose not to overwrite it. > I can choose to ensure that any cases where it is overwritten, it is > overwritten with a unique value. Random number does not provide this > level of control. > > > Maybe a good compromise that would allow a generator function to go into > > the backend would be to combine the current time with a random number. > > That will ensure that you won't get a dupe, so long as your clock never > > runs backwards. > > Which standard UUID generation function would you be thinking of? > Inventing a new one doesn't seem sensible. I'll have to read over the > versions again... I don't think it exists, but I don't see how that's an issue. Let's look at an extreme case: take the amount of random entropy used for the random-only generation method. Append that to the current time in UTC, and hash it. Thanks to the time component, you've now greatly reduced the odds of a duplicate, probably by many orders of magnitude. Ultimately, I'm OK with a generator that's only in contrib, provided that there's at least one that will work on all OSes. -- Jim Nasby jimn@enterprisedb.com EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-patches по дате отправления: