[EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 11:21:51PM -0400, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for
Jeremy Drake <[EMAIL PROTECTED]> writes:
> I must jump in with my amusement at this whole conversation. I just
> looked up the standard (http://www.ietf.org/rfc/rfc4122.txt) and it
> includes this abstract:
>A UUID is 128 bits long, and can guarantee
>uniqueness across space and time.
Th
[EMAIL PROTECTED] wrote:
Really this whole debate only reinforces the point that there isn't
a single way of doing UUID generation. There are multiple libraries
out there each with pros and cons. It makes more sense to have
multiple pgfoundry UUID generating modules.
Exactly. If I lead you to t
On Wed, Sep 20, 2006 at 05:04:00AM -0400, Gregory Stark wrote:
> [EMAIL PROTECTED] writes:
> > I have the impression I'm not being heard.
> > *I* control the MAC address assignment for all of *MY* units.
> No, you're missing the point. How does that help *me* avoid collisions with
> your UUIDs? UUI
Hi, Mark,
[EMAIL PROTECTED] wrote:
> The versions that include a MAC address, time, and serial number for
> the machine come pretty close, presuming that the user has not
> overwritten the MAC address with something else. It's unique at
> manufacturing time.
Not even that is guaranteed. I rememb
On Wed, 20 Sep 2006, Gregory Stark wrote:
>
> [EMAIL PROTECTED] writes:
>
> > I have the impression I'm not being heard.
> >
> > *I* control the MAC address assignment for all of *MY* units.
>
> No, you're missing the point. How does that help *me* avoid collisions with
> your UUIDs? UUIDs are sup
[EMAIL PROTECTED] writes:
> I have the impression I'm not being heard.
>
> *I* control the MAC address assignment for all of *MY* units.
No, you're missing the point. How does that help *me* avoid collisions with
your UUIDs? UUIDs are supposed to be unique period, not just unique on your
databa
Mark,A model that intended to try and guarantee uniqueness would provide aUUID generation service for the entire host, that was not specific to
any application, or database, possibly accessible via the loopbackaddress. It would ensure that at any given time, either the time isnew, or the sequence i
On Tue, Sep 19, 2006 at 11:21:51PM -0400, Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
> > On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > > > I would not use a 100% random number generator for a UUID val
[EMAIL PROTECTED] wrote:
> On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > > I would not use a 100% random number generator for a UUID value as was
> > > suggested. I prefer inserting the MAC address and the ti
On Tue, Sep 19, 2006 at 10:02:40PM -, Andrew - Supernews wrote:
> On 2006-09-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Different UUID forms can be unique within their domain. As long as I
> > control the MAC address assignment for all of my units, my MAC address
> > can be guaranteed
On 2006-09-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Different UUID forms can be unique within their domain. As long as I
> control the MAC address assignment for all of my units, my MAC address
> can be guaranteed to be unique across space and time,
You do not know (and can never know) t
On Tue, Sep 19, 2006 at 10:11:39AM -0400, Andrew Dunstan wrote:
> [EMAIL PROTECTED] wrote:
> >>As others have mentioned, using MAC address doesn't remove the
> >>possibility of a collision.
> >It does, as I control the MAC address. I can choose not to overwrite it.
> >I can choose to ensure that an
On Tue, Sep 19, 2006 at 09:51:23AM -0400, [EMAIL PROTECTED] wrote:
> On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > > I would not use a 100% random number generator for a UUID value as was
> > > suggested. I p
[-patches trimmed from list]
[EMAIL PROTECTED] wrote:
As others have mentioned, using MAC address doesn't remove the
possibility of a collision.
It does, as I control the MAC address. I can choose not to overwrite it.
I can choose to ensure that any cases where it is overwritten, it is
o
On Tue, Sep 19, 2006 at 03:35:55PM +0200, Gevik Babakhani wrote:
> > As others have mentioned, using MAC address doesn't remove the
> > possibility of a collision.
> >
> > Maybe a good compromise that would allow a generator function to go into
> > the backend would be to combine the current time
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > I would not use a 100% random number generator for a UUID value as was
> > suggested. I prefer inserting the MAC address and the time, to at
> > least allow me to c
> As others have mentioned, using MAC address doesn't remove the
> possibility of a collision.
>
> Maybe a good compromise that would allow a generator function to go into
> the backend would be to combine the current time with a random number.
> That will ensure that you won't get a dupe, so long
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> I would not use a 100% random number generator for a UUID value as was
> suggested. I prefer inserting the MAC address and the time, to at
> least allow me to control if a collision is possible. This is not easy
> to do using a fe
On Mon, Sep 18, 2006 at 04:17:50PM -0500, Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
> > I have UUID generation in core in my current implementation. In the
> > last year that I've been using it, I have already chosen twice to
> > generate UUIDs from my
On Mon, 2006-09-18 at 16:00 -0500, Jim C. Nasby wrote:
> BTW, at a former company we used SHA1s to identify files that had been
> uploaded. We were wondering on the odds of 2 different files hashing to
> the same value and found some statistical comparisons of probabilities.
> I don't recall the de
On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
> I have UUID generation in core in my current implementation. In the
> last year that I've been using it, I have already chosen twice to
> generate UUIDs from my calling program. I find it faster, as it avoids
> have to call out to
On Mon, Sep 18, 2006 at 04:00:22PM -0500, Jim C. Nasby wrote:
> BTW, at a former company we used SHA1s to identify files that had been
> uploaded. We were wondering on the odds of 2 different files hashing to
> the same value and found some statistical comparisons of probabilities.
> I don't recall
If you're going to yank it, please at least include a generator in
contrib.
Personally, I'd like to see at least some kind of generator in core,
with appropriate info/disclaimers in the docs. A simple random-number
generator is probably the best way to go in that regard. I think that
most people k
On Mon, Sep 18, 2006 at 10:33:22AM -0400, Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
> > there's a commonly accepted algorithm providing this.
> Anyone who thinks UUIDs are guaranteed unique has been drinking
"Harald Armin Massa" <[EMAIL PROTECTED]> writes:
> They also talk about a "guaranteed differentness" - and as much as I
> understand, they are Unique as long as the MAC-Adresses of the Network-Cards
> are unique, and fall back to "extremly likely" when there is no network card
> present.
MAC addre
On Mon, Sep 18, 2006 at 05:29:34PM +0200, Harald Armin Massa wrote:
> I would really like PostgreSQL to include an uuid-generation function
> crafted along the recommendations in rfc4122 or ISO/IEC 9834-8; so those
> UUIDs have a "ISO/IEC-defined uniqueness" or at least a "ISO/IEC-defined
> extreme
> Anyone who thinks UUIDs are guaranteed unique has been drinking too much> of the kool-aid.
> Identifier uniqueness considerations:> This document specifies three algorithms to generate UUIDs: the> first leverages the unique values of 802 MAC addresses to
> guarantee uniqueness, t
Completely agreed. I can remove the function from the patch. The
temptation was just too high not to include the new_guid() in the
patch :)
On Mon, 2006-09-18 at 10:33 -0400, Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > Isn't guaranteed uniqueness the very attribute that's exp
Am Montag, 18. September 2006 09:21 schrieb Andreas Pflug:
> Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
> there's a commonly accepted algorithm providing this.
There are several such algorithms, which is part of the problem. If someone
could sort that out, we might get
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
> there's a commonly accepted algorithm providing this.
Anyone who thinks UUIDs are guaranteed unique has been drinking too much
of the kool-aid. They're at best probably unique. Som
On Mon, 2006-09-18 at 11:11 +0200, Harald Armin Massa wrote:
> Gevik,
> >uniqueness is never a guaranteed. that is according to the RFC docs.
>
> >uniqueness is never a guaranteed in the sense that there is a tiny
> >chance someone of the other side of the planet might generate the
> same
> >guid
32 matches
Mail list logo
