Subject: uuid type not documented

From: Peter Eisentraut <[email-masked]>
Date: Tue, 10 Apr 2007 17:24:26 +0200

The new uuid type is lacking documentation.  Could you please work on that?  
At least assemble a list of things that exist so that others can build 
documentation around that.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---

From: Neil Conway <[email-masked]>
Date: Tue, 10 Apr 2007 11:30:30 -0400

On Tue, 2007-04-10 at 17:24 +0200, Peter Eisentraut wrote:
> The new uuid type is lacking documentation.

We had also talked about including some UUID generation functionality in
8.3, but it should be okay to leave that for 8.4.

-Neil

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 10 Apr 2007 18:28:57 +0200

> 8.3, but it should be okay to leave that for 8.4.

The problem is that most of the standard methods are platform dependent, as 
they require MAC addresses or a "good" random source, for instance.  I'm not 
sure how we wanted to solve that, but certainly leaving the uuid type with 
*no* method to generate one is pretty poor.

---

From: "Joshua D. Drake" <[email-masked]>
Date: Tue, 10 Apr 2007 09:34:42 -0700

> *no* method to generate one is pretty poor.

Actually, I would say that not having the ability to generate a UUID is 
just fine. Most languages, have the ability to generate them per their 
particular platforms. Let's leave it to them.

Sincerely,

Joshua D. Drake

-- 

       === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
              http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

---

From: Tom Lane <[email-masked]>
Date: Tue, 10 Apr 2007 13:07:29 -0400

> particular platforms. Let's leave it to them.

Let us *not* open that can of worms for 8.3.  This patch would not have
got in except that it didn't attempt to solve that problem, and there's
even less time available now.

			regards, tom lane

---

From: Neil Conway <[email-masked]>
Date: Tue, 10 Apr 2007 15:30:52 -0400

On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
> they require MAC addresses or a "good" random source, for instance.

http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php

ISTM random() or similar sources is a sufficient PSRNG for the purposes
of UUID generation -- I can't see anything in the RFC that would
contradict that.

-Neil

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 10 Apr 2007 15:49:08 -0400

> of UUID generation -- I can't see anything in the RFC that would

How about we set up a contrib (I wish we'd fixed that) module with an 
example function or two?

cheers

andrew

---

From: "Florian G. Pflug" <[email-masked]>
Date: Tue, 10 Apr 2007 22:04:36 +0200

> of UUID generation -- I can't see anything in the RFC that would

Maybe a short-term solution could be a UUID-generated function that
takes some kind of seed as a parameter. People not concerned about
collisons could just pass some random value, while others could use
the mac-address of the client or something similar.

greetings, Florian Pflug

---

From: Tom Lane <[email-masked]>
Date: Tue, 10 Apr 2007 17:25:05 -0400

> of UUID generation -- I can't see anything in the RFC that would

Doesn't seem like quite enough bits of uniqueness.

We could improve matters by incorporating the database's
pg_control.system_identifier into the UUID, substituting for the MAC
address we don't have a good way to get.  system_identifier is currently
determined by the system clock at initdb time (to gettimeofday
precision), so it would add at least some additional bits of
randomness...

			regards, tom lane

---

From: Roman Neuhauser <[email-masked]>
Date: Wed, 11 Apr 2007 07:28:17 +0200

# [email-masked] / 2007-04-10 15:49:08 -0400:
> >>The problem is that most of the standard methods are platform dependent, 
> >>as they require MAC addresses or a "good" random source, for instance.
> >>    
> >

Thought I'd mention Ralph Engelschall's uuid library, comes with
a PostgreSQL binding:

http://www.ossp.org/pkg/lib/uuid/
http://cvs.ossp.org/fileview?f=ossp-pkg/uuid/pgsql/uuid.txt&v=1.1

I only played with it some time ago.

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991

---

From: "Marko Kreen" <[email-masked]>
Date: Wed, 11 Apr 2007 09:46:51 +0300

> they require MAC addresses or a "good" random source, for instance.

FYI: good random source is already available in pgcrypto,
it uses either OpenSSL RAND_bytes() or internal strong PRNG.

-- 
marko

---

From: Gevik Babakhani <[email-masked]>
Date: Wed, 11 Apr 2007 14:07:55 +0200

Sorry for this late reply....
I go work on the docs. What is the deadline on this... (have to
rearrange some other things...)

---

From: Magnus Hagander <[email-masked]>
Date: Thu, 12 Apr 2007 09:14:27 +0200

The roadmap lists mid-may for all patches to be reviewed and applied, so
for a docs patch I guess we'd like to have it early may at the latest.

(We'll still accept docs patches later, but I think only when they're more
along the lines of correction, not when it's a whole feature that's not
documented)

//Magnus

On Wed, Apr 11, 2007 at 02:07:55PM +0200, Gevik Babakhani wrote:
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 20 Apr 2007 23:53:16 +0200

> rearrange some other things...)

I've written some basic documentation.  Please check 
<http://developer.postgresql.org/pgdocs/postgres/datatype.html> (in a 
while) to see if I got everything right.

---

From: Gevik Babakhani <[email-masked]>
Date: Mon, 14 May 2007 10:29:15 +0200

Hi,

I think the basic description for the UUID datatype is okay. Perhaps we
could add some basic examples to the documentation later. Thank you.

Regards,
Gevik.