From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Michael Satterwhite <michael(at)weblore(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: UUID column as pimrary key? |
Date: | 2011-01-06 15:59:56 |
Message-ID: | 9C94EDBC-B2C2-4540-9E45-11ACBB2DB5C8@elevated-dev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jan 6, 2011, at 8:19 AM, Michael Satterwhite wrote:
> That would be a matter of incompetent administration. *NOTHING* can protect
> against that.
Well, no, not necessarily. It might well be a goal (in fact, is a goal with some software that I'm developing), that users/admins don't have to worry about data caches moving across machines. My primary point, which I stated incompletely, was that in order to depend on node ids as part of unique ids, requires a degree of control over the administration of nodes, and for a given application this might or might not be practical. For instance, if your app runs on cell phones, and the OSs you deploy on give you access to the device id, and you don't mind using a rather long prefix to form your unique ids, then you have an obvious solution that, as far as I know, is guaranteed to be unique. (Ignoring the possibility of hacking of the device id, because no matter what you choose as a prefix, if an adversary manages to deliberately change the prefix, you can get duplicates.) My secondary point was that this is rather difficult to detect in time to prevent conflicts.
--
Scott Ribe
scott_ribe(at)elevated-dev(dot)com
http://www.elevated-dev.com/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Gary Chambers | 2011-01-06 16:21:18 | Re: pg_dump and database size question |
Previous Message | Adrian Klaver | 2011-01-06 15:55:38 | Re: UUID column as pimrary key? |