On Wed, Jan 05, 2011 at 06:22:08PM -0500, Chris Browne wrote: > But it seems to me that some of the analytics are getting a little *too* > paranoid, on the "perhaps UUIDs are the wrong answer" side of the > column. That could be. I was simply noting that there are cases where one could legitimately decide that the UUID is a bad fit. I was just objecting to the seeming (to me anyway) claim that UUIDs can always be used. > There's no panaceas, here; if the process that is using IDs is fragile, > then things can break down whether one is using UUID or SERIAL. Not necessarily. In a distributed system where some rows will sometimes (and unpredictably) be shared, guaranteeing that two systems cannot generate the same ID could be really important. In those cases, it's probably better to have a fixed generator ID plus a serial (or, for that matter, a UUID) because then you can be sure you don't run into one another. (Of course, some UUID examples already have this built in. It sort of depends on the algorithm one is using.) > I prefer the "probably unique enough" side of the fence, myself. Me too, most of the time. > And the process that uses the IDs needs to be robust enough that things > won't just fall apart in tatters if it runs into non-uniqueness. But that robustness requirement might be impossible in a distributed system, was all I was trying to point out. > It seems rather silly to be *totally* paranoid about the > not-infinite-uniqueness of UUIDs when there are plenty of other risks > lurking around that also need erro checking. I fully agree with this. 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
