[EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly