mark@mark.mielke.cc writes:
> In my choice of use, I'm using them instead of SERIAL columns, as I
> wish to have more freedom merging production data with test data. I
> wish to continually import production data into my test environment,
> in a single direction. UUID will prevent conflicts from occurring.
> SERIAL cannot (although in theory, I could set my copy of the serial
> value to 1 billion or something hacky - but that doesn't scale in a
> simple fashion to having several test environments).
Just do something like this for every sequence:
ALTER SEQUENCE foo INCREMENT BY 100
And then choose a particular initial value for each server.
I agree with the others that uuid seems to be overused in lots of cases where
a simple serial would serve just as well.
However I don't see why a good uuid type is any less of a valid addition to
the set of data types than any of the others. inet, macaddr, all the geometric
types, for example.
Given the 3-phase commit work going into 8.2 (8.1?) it seems like a pretty
fundamental component of that whole ball of wax. A note in the documentation
that it's designed for use as part of a multiple-database system like that
might be helpful.
--
greg
