| From: | John DeSoi <desoi(at)pgedit(dot)com> |
|---|---|
| To: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
| Cc: | Tino Wildenhain <tino(at)wildenhain(dot)de>, Riaan van der Westhuizen <riaan(at)huizensoft(dot)co(dot)za>, Postgresql-General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: GUID for postgreSQL |
| Date: | 2005-07-27 23:43:08 |
| Message-ID: | 6AEBFBA2-E181-4A33-95F8-0A94CCAD4F27@pgedit.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Jul 27, 2005, at 5:00 PM, Scott Marlowe wrote:
> Then I would think a better thought out solution would be one where
> your
> unique ids ARE guaranteed to be unique, where you used something like
>
> select 'astringuniqtothismachine'||nextval('localsequence');
>
> That really would be guaranteed unique as long as you set up each
> machine to have a string unique to it.
I have implemented this type of approach in distributed systems. The
problem is users who make a copy of their database, continue to use
both copies, and then call you when they try to merge things
together. I would say user opportunity to mess this up is way more
likely than having a GUID collision.
I'm not saying that GUIDs are the ultimate solution to this problem.
The original poster brought up the need to store GUIDs in a database.
There are protocols and standards that require GUIDs and I merely
agree it would be nice to have a GUID data type.
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dr NoName | 2005-07-28 00:12:46 | Re: transaction timeout |
| Previous Message | Alvaro Herrera | 2005-07-27 23:35:31 | Re: GUID for postgreSQL |