Dann Corbit wrote:
There is a "privacy hole" from using the MAC address. (Read it in the
WIKI article someone else posted).
Probably, it would be better to use a one way hash of the MAC address.
The chances of MAC addresses colliding (through some low-end network
card vendor's sloppy manufac
On Fri, Jul 29, 2005 at 12:18:30 -0400,
"John D. Burger" <[EMAIL PROTECTED]> wrote:
> >If you use a large enough space for the number you can reduce that
> >probability of an accidental collision to much less than that of
> >catastrophic hardware failure at which point it isn't noticably better
>
"John D. Burger" <[EMAIL PROTECTED]> writes:
> > If you use a large enough space for the number you can reduce that
> > probability of an accidental collision to much less than that of
> > catastrophic hardware failure at which point it isn't noticably better
> > than having no chance of collisio
If you use a large enough space for the number you can reduce that
probability of an accidental collision to much less than that of
catastrophic hardware failure at which point it isn't noticably better
than having no chance of collisions.
I find the comparison unconvincing - if my hardware cras
On 07/28/2005-05:55AM, Stefan 'Kaishakunin' Schumacher wrote:
>
> 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
>
16 BYTE not bit. From the wiki...
A U
On Wed, Jul 27, 2005 at 16:57:21 -0400,
John DeSoi <[EMAIL PROTECTED]> 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 o
[EMAIL PROTECTED] ("Stefan 'Kaishakunin' Schumacher") writes:
> So as I understand the GUIDs only apply to the Microsoft Universe[TM], or
> are there any other serious apllications using it?
No, the RFC (4122) was written by a combination of people including
Rich Salz, and is an encoding of the DC
[EMAIL PROTECTED] (Scott Marlowe) writes:
> 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()
>>
[EMAIL PROTECTED] (Chris Travers) writes:
>>At least on Windows, the GUID is derived in part from the computers
>>primary MAC address. No, it's not a guarantee, but it's pretty unlikely
>>:-)
> The danger is not that the MAC address will be duplicated, but that
> other factors will lead to an MD5
Also sprach Scott Marlowe ([EMAIL PROTECTED])
> 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
> >
I don't think it would be that slow, unless running on a modem.
It would really depend on what you are doing, calling dblink 1000 times
a second would be slow, but I could see it being
used succesfully for other applications.
Alvaro Herrera wrote:
On Wed, Jul 27, 2005 at 05:40:11PM -0500, Ton
On Wed, Jul 27, 2005 at 07:43:08PM -0400, John DeSoi wrote:
> 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 n
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 uniqu
On Wed, Jul 27, 2005 at 05:40:11PM -0500, Tony Caduto wrote:
> Use Dblink and do a select off of a sequence on just one of the boxes?
> You could set up a view that uses DBlink on all the boxes that points to
> the master seq box.
>
> should work.
It'll make the whole thing painfully slow.
--
Use Dblink and do a select off of a sequence on just one of the boxes?
You could set up a view that uses DBlink on all the boxes that points to
the master seq box.
should work.
Scott Marlowe wrote:
So, how can two databases, not currently talking to one another,
guarantee that their GUIDs do
Am Mittwoch, den 27.07.2005, 23:03 +0200 schrieb Magnus Hagander:
> > > 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
On Behalf Of Chris Travers
> Sent: Wednesday, July 27, 2005 2:27 PM
> To: Magnus Hagander; pgsql-general
> Subject: Re: [GENERAL] GUID for postgreSQL
>
> Magnus Hagander wrote:
>
> >>
> >
> >At least on Windows, the GUID is derived in part from the computers
Magnus Hagander wrote:
At least on Windows, the GUID is derived in part from the computers
primary MAC address. No, it's not a guarantee, but it's pretty unlikely
:-)
The danger is not that the MAC address will be duplicated, but that
other factors will lead to an MD5 collision.
Unless
You could guarantee it, for example...
Something like (pseudocode here):
create sequence local_id;
create domain guid AS text default ('54-' || (nextval(local_id))::text);
where 54 is the database id. In this way, every inserted GUID will be
guaranteed to contain a GUID in two parts: A databas
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 collis
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
> > 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
> >
huizen; Postgresql-General
> Subject: Re: [GENERAL] GUID for postgreSQL
>
> 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_u
Yes, this is the problem with GUIDs... you can calculate them by mashing
toghether things like the time, a network address, and some random
numbers, which makes it very unlikely for a collision but at the end
of the day that G stand for global, *not* guaranteed.
On Wed, 27 Jul 2005, Scott Marl
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
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 new
Hi Riaan.!
i think that is a better solution, to use the postgres native type
"serial", that it is a autoincremental number type. You can see it
on the postgres manual. It's very usefull because of you only need to
redifine the type of your id vars. For example, on this moment you
have
CREA
Am Mittwoch, den 27.07.2005, 09:48 +0200 schrieb Riaan van der
Westhuizen:
> Hi All,
>
> We are a small developing house in South Africa, which is in the process of
> porting our Apps from
> MS SQL to PostgreSQL. We use the newid() [globally unique identifier
> (GUID)] function in SQL a lot, an
28 matches
Mail list logo
