Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 8F794650054 for ; Tue, 12 Aug 2008 12:48:37 -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 53366-04 for ; Tue, 12 Aug 2008 12:48:31 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id 1A94464FCFC for ; Tue, 12 Aug 2008 12:48:31 -0300 (ADT) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 12 Aug 2008 11:48:30 -0400 id 0005641D.48A1B0CE.00012B34 Date: Tue, 12 Aug 2008 11:48:40 -0400 From: Bill Moran To: Steve Atkins Cc: PostgreSQL Performance Subject: Re: Using PK value as a String Message-Id: <20080812114840.8f7468ed.wmoran@collaborativefusion.com> In-Reply-To: <233F1248-E3EA-4572-9310-4E4BC13995DE@blighty.com> 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> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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/131 X-Sequence-Number: 31012 In response to Steve Atkins : > > On Aug 12, 2008, at 8:21 AM, Bill Moran wrote: > > > In response to Moritz Onken : > > > >> > >> Am 12.08.2008 um 17:04 schrieb Bill Moran: > >> > >>> In response to Moritz Onken : > >>> > >>>> 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. > >>> > >>> So you're accidentally storing critical information in magic values > >>> instead of storing it explicitly? > >>> > >>> Good luck with that. > >> > >> How do I store critical information? I was just saying that it easy > >> to get some information out of a primary key which is an incrementing > >> integer. And it makes sense, in some rare cases, to have a PK which > >> is some kind of random like UUIDs where you cannot guess the next > >> value. > > > > I just repeated your words. Read above "this is information which > > is in > > some cases critical." > > > > If I misunderstood, then I misunderstood. > > > > 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. Then I did misunderstand. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023