On Sep 6, 2005, at 12:57 PM, Jonah H. Harris wrote:
On 9/6/05, Josh Berkus <josh@agliodbs.com> wrote: Mark,
> I suggest that UUID be recommended in place of SERIAL for certain
> classes of applications, and that it therefore belongs in the core.
> UUID and SERIAL can be used together (although, once you have a UUID,
> it may not be useful to also have a SERIAL).
I think that, if you want to push a refactored UUID type for PostgreSQL
8.2, that you'd better separate your database design arguments from your
inclusion arguments.
For example, you might get my agreement that it would be useful to have a
UUID as a core type; you would *never* get my agreement to recommend using
UUID to newbies. I have seen *far* too many abuses of UUIDs in really
bad database design. People who use them should be experienced enough to
know what they're doing.
I agree with Josh on the UUID type, it gets abused far too often and (IMHO) isn't widely enough used to belong in the core. Couldn't you just fix the problem in pguuid rather than write a whole new type?
This sounds like a strawman argument. People abuse a lot of types to do a lot of things they shouldn't be doing, adding types to the core isn't really going to change that much one way or the other.
If the documentation gives the user a good idea of when to use UUID and when not, I think it would be a good addition. Worst case, it could become part of contrib, so at least it ships with PostgreSQL with the same license. The GPL license of pguuid is a show-stopper for some (and seems like a silly choice for what it is and who it's for).
-bob