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

Re: [GENERAL] UUID's as primary keys

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Thomas Hallgren <thomas(at)tada(dot)se>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] UUID's as primary keys
Date: 2006-06-29 16:47:17
Message-ID: 20060629164717.GF16792@svana.org (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On Thu, Jun 29, 2006 at 06:40:13PM +0200, Thomas Hallgren wrote:
> Martijn van Oosterhout wrote:
> >On Thu, Jun 29, 2006 at 03:54:36PM +0200, Thomas Hallgren wrote:
> >  
> >>I have to concur with this. Assume you use a bytea for a UUID that in 
> >>turn is used as a primary key. The extra overhead will be reflected in 
> >>all indexes, all foreign keys, etc. In a normalized database some tables 
> >>may consist of UUID columns only.
> >>    
> >
> >So you create a UUID type. It's cheap enough to create new types after
> >all, that's one of postgresql's strengths.
> It would be a whole lot easier if I could use a domain.

It seems to me that maybe the backend should include a 16-byte fixed
length object (after all, we've got 1, 2, 4 and 8 bytes already) and
then people can use that to build whatever they like, using domains,
for example...

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog(at)svana(dot)org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2006-06-29 16:59:26
Subject: Re: Single Index Tuple Chain (SITC) method
Previous:From: Tom LaneDate: 2006-06-29 16:41:29
Subject: Re: Index corruption

pgsql-general by date

Next:From: Chris BrowneDate: 2006-06-29 18:30:34
Subject: Re: Database connectivity using a unix shell
Previous:From: Richard Broersma JrDate: 2006-06-29 16:47:15
Subject: Re: Database connectivity using a unix shell

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