Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Patch for UUID datatype (beta)

From: mark(at)mark(dot)mielke(dot)cc
To: "Jim C(dot) Nasby" <jimn(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,Gevik Babakhani <pgdev(at)xs4all(dot)nl>,pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Patch for UUID datatype (beta)
Date: 2006-09-18 23:45:07
Message-ID: 20060918234507.GA16056@mark.mielke.cc (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mon, Sep 18, 2006 at 04:17:50PM -0500, Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 12:23:16PM -0400, mark(at)mark(dot)mielke(dot)cc 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.

contrib module.

> > 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.

Then load the contrib module. I do both. I'd happily reduce my contrib
module to be based upon a built-in UUID type within PostgreSQL, providing
the necessary UUID generation routines.

I would not use a 100% random number generator for a UUID value as was
suggested. I prefer inserting the MAC address and the time, to at
least allow me to control if a collision is possible. This is not easy
to do using a few lines of C code. I'd rather have a UUID type in core
with no generation routine, than no UUID type in core because the code
is too complicated to maintain, or not portable enough.

Cheers,
mark

-- 
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


In response to

Responses

pgsql-hackers by date

Next:From: Golden LiuDate: 2006-09-19 01:33:15
Subject: Re: Unique index: update error
Previous:From: Tom DunstanDate: 2006-09-18 23:43:19
Subject: Re: An Idea for OID conflicts

pgsql-patches by date

Next:From: Gregory StarkDate: 2006-09-19 09:44:10
Subject: More doc patches
Previous:From: Gavin SherryDate: 2006-09-18 22:35:17
Subject: Re: Latest Bitmap Index patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group