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.wagner@xxxxxxxxx> wrote:
On 1/17/07, Patrick Earl <patearl@xxxxxxxxxxx> 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/
