From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | nathan wagner <nw(at)hydaspes(dot)if(dot)org> |
Subject: | Re: uuid type for postgres |
Date: | 2005-09-07 18:31:16 |
Message-ID: | 200509071131.17161.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Nathan,
> I was thinking of cryptographic applications. Then, to use an
> example from another domain, initial TCP sequence numbers should
> be random (i.e. unguessable). A problem with TCP perhaps. It's
> been a while since i've read over my copy of _Applied Cryptography_,
> but I seem to recall that unguessable numbers were sometimes useful.
Yeah, the problem is what it does to your data. If there's no analyzable
correspondence between the key and the server/table/row it attaches to,
then you have no way to detect if the key and the data have become
disassociated.
This is, btw, a problem with conventional SERIALs as well. "unguessable"
UUIDs just compound the problem by adding additional variables (the server
and the table), as well as generally leading to applications which depend
*entirely* on UUID-based integrity and thus can't cope with any failures
in UUID generation or transmission.
I'm also a little baffled to come up with any real application where making
an id number for most tables "unguessable" would provide any kind of real
protection not far better provided by other means. For your "users"
table, sure, but that's a very special case.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Lee, Patricia S. | 2005-09-07 18:31:40 | PostgreSQL from source using MinGW |
Previous Message | Tom Lane | 2005-09-07 18:01:55 | Re: uuid type for postgres |
From | Date | Subject | |
---|---|---|---|
Next Message | Bob Ippolito | 2005-09-07 18:47:23 | Re: uuid type for postgres |
Previous Message | Tom Lane | 2005-09-07 18:01:55 | Re: uuid type for postgres |