Re: uuid type for postgres

mark(at)mark(dot)mielke(dot)cc writes:
> Personally, I'm not sure what the big opposition to UUID is all about.

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
unmaintained cruft in the core distro already (eg, the never-finished
"line" datatype ... or the entire rtree index module ...) and a datatype
that might be used by only a few people is a likely candidate to become
an unmaintained backwater. And yet it's hard to get rid of stuff that's
been there awhile. So one of the questions that's going to be asked is
how useful/popular it's really going to be.

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.

The bottom line is that we're willing to listen, but it's not by any
means a slam dunk to get this into the distribution.

regards, tom lane