[EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
