Re: uuid type for postgres
От | Jonah H. Harris |
---|---|
Тема | Re: uuid type for postgres |
Дата | |
Msg-id | 36e682920509061627570d03a0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: uuid type for postgres (Bob Ippolito <bob@redivi.com>) |
Список | pgsql-hackers |
Tom, you worded my thoughts much better than I did.
Bob, I too had heard that host-based UUIDs/GUIDs had issues with uniqueness. I think Microsoft's implementation was hosed and they ended up eliminating using the MAC completely.
I'll check out the code & get back.
Bob, I too had heard that host-based UUIDs/GUIDs had issues with uniqueness. I think Microsoft's implementation was hosed and they ended up eliminating using the MAC completely.
I'll check out the code & get back.
On 9/6/05, Bob Ippolito <bob@redivi.com> wrote:
On Sep 6, 2005, at 3:06 PM, mark@mark.mielke.cc wrote:
> On Tue, Sep 06, 2005 at 05:54:34PM -0400, Tom Lane wrote:
>
>> I don't see any "big opposition". People are simply questioning the
>> idea whether it belongs in core PG. The reason we don't want to
>> accept
>> everything-and-the-kitchen-sink in core is that we have only limited
>> manpower to maintain it. So you've got to justify that we should
>> spend
>> our effort here and not elsewhere. There's a fair amount of nearly
>> ...
>> been there awhile. So one of the questions that's going to be
>> asked is
>> how useful/popular it's really going to be.
>>
>
> Sounds reasonable, and certainly no more than I expected. If Nathan
> hadn't raised the issue, it probably would have been a few months
> before I raised it myself.
>
>
>> One thing that is raising my own level of concern quite a bit is the
>> apparent portability issues. Code that isn't completely portable
>> is a
>> huge maintainability problem; in particular, stuff that requires
>> system-dependent behavior used nowhere else in Postgres is a real
>> pain.
>> It sounds like the UUID code expects to be able to get at the
>> machine's
>> MAC address, which suggests serious issues in (a) relying on
>> not-too-standard APIs, (b) possible protection issues (will an
>> unprivileged process be able to get at the MAC address?), and (c)
>> ill-defined behavior on machines with more or less than one MAC
>> address.
>> Not to mention that MAC addresses aren't so unique as all that.
>>
>
> I'll try to prepare an answer for this. (I started to write a lot of
> information - but is it unverified from memory, and perhaps should be
> more authoritative before presented as truth)
Some modern UUID implementations prefer /dev/urandom or similar to
the time or MAC address unless you really beg them to give you a
weaker UUID.
You can take a look at the man page for the Theodore Y. Ts'o
implementation that is in Darwin's Libc here:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/
man3/uuid_generate.3.html
Specifically:
The uuid_generate function creates a new universally unique
identifier
(UUID). The uuid will be generated based on high-quality
randomness
from /dev/urandom, if available. If it is not
available, then
uuid_generate will use an alternative algorithm which uses
the current
time, the local ethernet MAC address (if available), and
random data
generated using a pseudo-random generator.
The Apache Portable Runtime has a apr_os_uuid_get() that supports two
flavors of UUID for unix (Linux/Mac OS X uuid_generate and FreeBSD's
uuid_create, may be available elsewhere), and the UuidCreate API on
Win32. apr-util's apr_uuid_get() will use apr_os_uuid_get() if
available, and otherwise will default to a relatively weak mostly-
timestamp-based UUID.
It would probably be reasonable and easy to do what Apache does
here. A platform UUID implementation, if present, is generally going
to be better than anything included into PostgreSQL itself.
-bob
В списке pgsql-hackers по дате отправления: