By its definition, GUID (
http://en.wikipedia.org/wiki/GUID ) is not guaranteed to be unique. As a result, it could cause problems in tables that have a large number of rows - actually this could result in hard to reproduce, seemingly random errors in your systems that use the database. How does a GUID help you over a BIGSERIAL?
Unless you are generating the PK in multiple databases, a BIGSERIAL should act as a UUID.
Maybe if you provide a little more detail on why you want to use GUID or UUID fields we can help you come up with more options.
Thanks,
Aaron
On 6/26/06, Dennis Wagner <wagner@spheron.com> wrote: Hi list!
I'm currently thinking about using GUIDs as primary keys. To be more
precise: On *some* of the tables in my structure I *will* need GUIDs (or
UUIDs or whatever format may proove usefull). Now, this implies that
using a bigserial-field for readability and the uids is redundand, so
I'm thinking of dropping my current primary-key-columns in favor of an
uuid-column.
In the postgres-docs I can't find any built-in data-types directly
supporting guids. I found the project pguuid on gborg but it somehow
lacks documentation and doesn't seem very promising (since it doesn't
seem to be touched since three years ago...).
I have found some older discussion on the archives but in the end noone
ever came up with THE solution nor did anyone talk about the
performance-impact using a guid-row as primary key would have over
using, let's say bigint.
Has anyone made some test in this field and can share some experiences?
Would this question be better placed in the hackers list?
Best regards
Dennis