Re: GUID for postgreSQL

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: GUID for postgreSQL
Дата
Msg-id 1122497203.15145.125.camel@state.g2switchworks.com
обсуждение исходный текст
Ответ на Re: GUID for postgreSQL  (John DeSoi <desoi@pgedit.com>)
Ответы Re: GUID for postgreSQL  (John DeSoi <desoi@pgedit.com>)
Re: GUID for postgreSQL  (Ben <bench@silentmedia.com>)
Re: GUID for postgreSQL  (Tony Caduto <tony_caduto@amsoftwaredesign.com>)
Список pgsql-general
On Wed, 2005-07-27 at 15:32, John DeSoi wrote:
> On Jul 27, 2005, at 4:49 AM, Tino Wildenhain wrote:
>
> > I'd create a sequence:
> >
> > CREATE SEQUENCE global_unique_id_seq;
> >
> > and a function:
> >
> > CREATE OR REPLACE FUNCTION newid()
> >   RETURNS text AS
> > $BODY$ SELECT nextval('global_unique_id_seq')::text; $BODY$
> >   LANGUAGE 'sql' VOLATILE;
> >
> >
> > now every call to newid() returns a garantied unique id for
> > say the next 18446744073709551616 calls.
> > Of course you can obfuscate the ID even more using
> > md5, include servername and so on, but this will not improve
> > security in any way (unless you mix data with 2nd database)
>
>
> This is not really a viable replacement for a GUID == globally unique
> identifier. Here global means that if I use the application in
> multiple databases, I'm guaranteed that no two identifiers will be
> the same. Using a sequence will only support uniqueness for a single
> database.

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.

В списке pgsql-general по дате отправления:

Предыдущее
От: Brian Wong
Дата:
Сообщение: Re: DELETE with JOIN syntax
Следующее
От: "Dann Corbit"
Дата:
Сообщение: Re: GUID for postgreSQL