Re: Using PK value as a String - Mailing list pgsql-performance

From Mark Mielke
Subject Re: Using PK value as a String
Date
Msg-id 48A1B2A6.4060003@mark.mielke.cc
Whole thread Raw
In response to Re: Using PK value as a String  (Bill Moran <wmoran@collaborativefusion.com>)
List pgsql-performance
Bill Moran wrote:
>>>>>> We chose UUID as PK because there is still some information in an
>>>>>> integer key.
>>>>>> You can see if a user has registered before someone else
>>>>>> (user1.id <
>>>>>> user2.id)
>>>>>> or you can see how many new users registered in a specific period
>>>>>> of
>>>>>> time
>>>>>> (compare the id of the newest user to the id a week ago). This is
>>>>>> information
>>>>>> which is in some cases critical.
>> I think Moritz is more concerned about leakage of critical information,
>> rather than intentional storage of it. When a simple incrementing
>> integer
>> is used as an identifier in publicly visible places (webapps, ticketing
>> systems) then that may leak more information than intended.
>>

While we are on this distraction - UUID will sometimes encode "critical"
information such as: 1) The timestamp (allowing users to be compared),
and 2) The MAC address of the computer that generated it.

So, I wouldn't say that UUID truly protects you here unless you are sure
to use one of the UUID formats that is not timestamp or MAC address
based. The main benefit of UUID here is the increased keyspace, so
predicting sequence becomes more difficult.

(Note that an all-random UUID is not better than two pairs of all-random
64-bit integers with a good random number source. :-) )

Cheers,
mark

--
Mark Mielke <mark@mielke.cc>


pgsql-performance by date:

Previous
From: Bill Moran
Date:
Subject: Re: Using PK value as a String
Next
From: "Merlin Moncure"
Date:
Subject: Re: long transaction