On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote: > I have UUID generation in core in my current implementation. In the > last year that I've been using it, I have already chosen twice to > generate UUIDs from my calling program. I find it faster, as it avoids > have to call out to PostgreSQL twice. Once to generate the UUID, and > once to insert the row using it. I have no strong need for UUID > generation to be in core, and believe there does exist strong reasons > not to. Performance is better when not in core. Portability of > PostgreSQL is better when not in core. Ability to control how UUID is > defined is better when not in control. That's kinda short-sighted. You're assuming that the only place you'll want to generate UUIDs is outside the database. What about a stored procedure that's adding data to the database? How about populating a table via a SELECT INTO? There's any number of cases where you'd want to generate a UUID inside the database.
> The only thing an in-core version provides is convenience for those > that do not have easy access to a UUID generation library. I don't > care for that convenience. It's not about access to a library, it's about how do you get to that library from inside the database, which may not be very easy. You may not care for that convenience, but I certainly would. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
