Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id E995D6501B1 for ; Tue, 12 Aug 2008 12:57:02 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 62591-03 for ; Tue, 12 Aug 2008 12:56:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by postgresql.org (Postfix) with SMTP id 6D22A650230 for ; Tue, 12 Aug 2008 12:56:24 -0300 (ADT) Received: (qmail 54960 invoked from network); 12 Aug 2008 15:56:23 -0000 Received: from unknown (HELO ?99.245.226.206?) (markmielke@rogers.com@99.245.226.206 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 12 Aug 2008 15:56:23 -0000 X-YMail-OSG: kZ4dpIsVM1mb4.Yzbyg9gkDTstTco6uJb7z8K0DuDrvQQUhKRf8ranN3ICPSiZlWEg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A1B2A6.4060003@mark.mielke.cc> Date: Tue, 12 Aug 2008 11:56:22 -0400 From: Mark Mielke User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Bill Moran CC: Steve Atkins , PostgreSQL Performance Subject: Re: Using PK value as a String References: <18986.60888.qm@web25807.mail.ukl.yahoo.com> <48A15ECF.5030203@sime.com> <87od3ywg4n.fsf@oxford.xeocode.com> <0673579A-B049-4619-B6E4-EE427FB0DDBA@globalinn.com> <1343069D-263F-4D99-BF7E-269C8F0E7F1F@houseofdesign.de> <20080812110416.8e0d6e1c.wmoran@collaborativefusion.com> <4D558373-E7B0-40EC-95EF-FDFE7046ABA2@houseofdesign.de> <20080812112136.72af4bff.wmoran@collaborativefusion.com> <233F1248-E3EA-4572-9310-4E4BC13995DE@blighty.com> <20080812114840.8f7468ed.wmoran@collaborativefusion.com> In-Reply-To: <20080812114840.8f7468ed.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/132 X-Sequence-Number: 31013 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