From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com>, David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Drawbacks of using BYTEA for PK? |
Date: | 2004-01-12 10:04:04 |
Message-ID: | 200401121004.04173.dev@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sunday 11 January 2004 22:05, D. Dante Lorenso wrote:
> David Garamond wrote:
> > Are there any drawbacks of using BYTEA for PK compared to using a
> > primitive/atomic data types like INT/SERIAL? (like significant
> > performance hit, peculiar FK behaviour, etc).
> >
> > I plan to use BYTEA for GUID (of course, temporarily I hope, until
> > PostgreSQL officially supports GUID data type), since it seems to be
> > the most convenient+compact compared to other data types currently
> > available. I use GUIDs for most PK columns.
>
> GUID? Isn't that really nothing more than an MD5 on a sequence?
>
> SELECT (MD5(NEXTVAL('my_table_seq'))) AS my_guid;
I think the point of a GUID is it's supposed to be unique across any number of
machines without requiring those machines to coordinate their use of GUID
values.
I think the typical approach is to use something like:
hash_fn( network_mac_address || other_hopefully_unique_constant ||
sequence_val )
and make sure that the probability of getting collisions is acceptably low.
ISTR a long discussion a year or two back on one of the lists, for those that
are interested.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2004-01-12 10:12:07 | Re: insertion with trigger failed unexpectedly |
Previous Message | Richard Huxton | 2004-01-12 09:57:32 | Re: Case sensitivity |