On Wed, Jan 05, 2011 at 07:46:18PM -0700, Scott Ribe wrote: > And if somebody clones the disk to a new machine, but leaves the old one in service? Or do you use the MAC address and hope that's unique? > Excellent questions, and exactly the sort (as I was arguing elsewhere in this thread) one has to answer in order to decide what the right strategy is. For instance, it may be that your application need is dealing with incredibly valuable identifiers, that not cloning the disk is a matter of national security, that the cost of finding and fixing a failed unique identification case runs into the billions of dollars (not to mention the millions of deaths), and that the assignment is performed in real time by distributed systems that only eventually, if at all, deliver data to a unified system. In this case, the cost of the failure of uniqueness is very high, and it would be prudent to arrange something that guaranteed that no assigner node could possibly create a duplicate identifier. There are UUID approaches that can do this; they mostly work by guaranteeing a fixed and assignable local part. UUID vs. serial for one of those columns seems to me to be nothing but an application efficiency problem. What is far more likely is that ordinary-value identifiers are being generated, and that you are using them for more or less pedestrian reasons. The cost of an undetected duplicate is still maybe millions of dollars, but the chances of a duplicate going undetected at creation time (like, say, the MAC address of the creating machine is used, the useful lifetime of the UUID is on the order of single-digit years, and there are no more than 10 database back ends involved) are fairly low. In this case, using a proven UUID generator seems like a no-brainer to me (and in fact, I work on an application where we do this). I don't understand the number of knees in this conversation that seem to be jerking against the answer, "It depends." Of course it depends. If there were one answer for everything, developing good database-backed systems wouldn't be something people would pay any of us for. A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general