Re: uuid type for postgres
От | Bob Ippolito |
---|---|
Тема | Re: uuid type for postgres |
Дата | |
Msg-id | 75CDCC93-EF09-4ED5-9770-55F49BF48614@redivi.com обсуждение исходный текст |
Ответ на | Re: uuid type for postgres (mark@mark.mielke.cc) |
Ответы |
Re: uuid type for postgres
("Jonah H. Harris" <jonah.harris@gmail.com>)
|
Список | pgsql-hackers |
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 по дате отправления: