Re: GUID for postgreSQL

From: "Stefan 'Kaishakunin' Schumacher" <stefan(at)net-tex(dot)de>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: John DeSoi <desoi(at)pgedit(dot)com>, 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-28 03:55:32
Message-ID: 20050728035532.GA949@aragorn.net-tex.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Also sprach Scott Marlowe (smarlowe(at)g2switchworks(dot)com)
> On Wed, 2005-07-27 at 15:57, John DeSoi wrote:
> > On Jul 27, 2005, at 4:46 PM, Scott Marlowe wrote:
> >
> > > So, how can two databases, not currently talking to one another,
> > > guarantee that their GUIDs don't collide? using a large randomly
> > > generated name space only reduces the chances of collision, it doesn't
> > > actually guarantee it.
> >
> >
> > Like MD5, there is no 100% guarantee, but the collision possibility
> > supposed to be is very close to zero.
>
> 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 was a little bit confused about the uniqueness of GUID (esp. using
only 16 Bit [1]) and read the article about the UUID:
http://en.wikipedia.org/wiki/Universally_Unique_Identifier

It states:

Conceptually, the original (version 1) generation scheme for UUIDs was
to concatenate the UUID version with the MAC address of the computer
that is generating the UUID, and with the number of 100-nanosecond
intervals since the adoption of the Gregorian calendar. In practice,
the actual algorithm is more complicated. This scheme has been
criticized in that it is not sufficiently 'opaque'; it reveals both
the identity of the computer that generated the UUID and the time at
which it did so.

Several other generation algorithms have been developed and
incorporated into the standard, including a scheme relying only on
random numbers (version 4 UUIDs), and a scheme deriving a UUID from a
URL via MD5 (version 3 UUIDs) or SHA-1 (version 5 UUIDs) hashing.

The 5.0 release of Java provides a class that will produce 128-bit
UUIDs. The API documentation for the java.util.UUID class refers to
ISO/IEC 11578:1996.

So as I understand the GUIDs only apply to the Microsoft Universe[TM], or
are there any other serious apllications using it?

I don't see any value of that, if not all real databases support one
GUID standard (with more than 16 Bit) worldwide. It might also be a
good idea to reserve space of the hash to identify the database
(vendor), just like FCC IDs or MACs do, but that would require a
central authority assigning those names and numbers.

[1] Why do people want to have IPv6?
--
PGP FPR: CF74 D5F2 4871 3E5C FFFE 0130 11F4 C41E B3FB AE33
--
Der Geist des Kriegers sollte mit Beginn des Neujahrstages bis zum Ende
des Jahres vom Gedanken an seinen Tod beherrscht werden.

Daijouji Shigesuke in "Budo Shoshin Shuu"

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Travers 2005-07-28 04:16:04 Re: [GENERAL] MySQL to PostgreSQL, was ENUM type
Previous Message Chris Travers 2005-07-28 03:49:51 Re: Upgrading from 7.1