Re: GUID/UUID Support

From: "Patrick Earl" <patearl(at)patearl(dot)net>
To: "Chad Wagner" <chad(dot)wagner(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: GUID/UUID Support
Date: 2007-01-18 17:31:26
Message-ID: e0762e610701180931r94fef05o7da7fc05fe719101@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

One issue is that UUIDs are only 16 bytes of data. To store the as
text in canonical form requires 36 bytes. As there are alternate
frequently used representations, you also run into potential issues
with input. The GUID type (proposed by Gevik) handles those standard
input variations.

Though I haven't tried it, I would imagine there would be performance
implications when using 36 character keys everywhere to do indexing,
joins, etc.

Another issue is that higher level languages (such as Delphi and .NET)
have GUID field types built in. If the field is just a string field,
it won't map nicely to those higher level types.

Patrick

On 1/17/07, Chad Wagner <chad(dot)wagner(at)gmail(dot)com> wrote:
> On 1/17/07, Patrick Earl <patearl(at)patearl(dot)net> wrote:
> > Certainly support for the GUID field type itself is most important.
> > As for the generators, though they are non-essential, they are very
> > useful. Other platforms and libraries have standardized on uuid
> > generators, so I don't see why PostgreSQL can't.
>
> Maybe I am oblivious to the reason, but why is there a need for a special
> data type for GUID/UUIDs? Wouldn't you always be doing an "equality"
> anyways? Wouldn't a varchar suffice?
>
> --
> Chad
> http://www.postgresqlforums.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Ribe 2007-01-18 17:43:41 Clearing plans
Previous Message Tom Lane 2007-01-18 16:52:23 Re: Corrupt database? 8.1/FreeBSD6.0