On Sep 6, 2005, at 3:06 PM, [EMAIL PROTECTED] 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
