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 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
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
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
If you have trouble with duplicate OIDs
Please use patch-0.2 for testing. I have changed the OIDs to 5000 range.
You can download it from:
http://www.truesoftware.net/pgsql/uuid/patch-0.2/
On Mon, 2006-09-18 at 01:00 +0200, Gevik Babakhani wrote:
> Folks,
>
> The following patch implements the
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
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
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
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. As much as I learned, it is recommended to give information about "grade of un
On Mon, 2006-09-18 at 09:21 +0200, Andreas Pflug wrote:
> Gevik Babakhani wrote:
> > - new_guid() function is supported. This function is based on V4 random
> > uuid value. It generated 16 random bytes with uuid 'variant' and
> > 'version'. It is not guaranteed to produce unique values
>
> Isn't
Gevik Babakhani wrote:
> - new_guid() function is supported. This function is based on V4 random
> uuid value. It generated 16 random bytes with uuid 'variant' and
> 'version'. It is not guaranteed to produce unique values
Isn't guaranteed uniqueness the very attribute that's expected? AFAIK
ther
Folks,
The following patch implements the UUID datatype. I would like to send
this beta patch to see if I still am on the right track. Please send
your comments.
Description of UUID:
- The type is called uuid.
- btree and hash indexes are supported.
- uuid array is supported.
- uuid text i/o is
19 matches
Mail list logo
