X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 4B7AE9F94F3 for ; Thu, 6 Jul 2006 18:51:38 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 33948-04 for ; Thu, 6 Jul 2006 18:51:34 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id F1F369FA0EC for ; Thu, 6 Jul 2006 18:51:34 -0300 (ADT) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Jul 2006 21:51:33 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 06 Jul 2006 16:51:33 -0500 Subject: Re: Alternative to serial primary key From: Scott Marlowe To: Sander Steffann Cc: operationsengineer1@yahoo.com, pgsql-sql@postgresql.org In-Reply-To: <001b01c6a145$84e7ffd0$64c8a8c0@balefirehome> References: <20060706183920.46008.qmail@web33314.mail.mud.yahoo.com> <12b7ac1e0607061330o34adbd6ds9bd624d3889c7fe7@mail.gmail.com> <001b01c6a145$84e7ffd0$64c8a8c0@balefirehome> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1152222693.13851.283.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 06 Jul 2006 16:51:33 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/75 X-Sequence-Number: 25649 On Thu, 2006-07-06 at 16:45, Sander Steffann wrote: > Hi, > > > But having a hash function over the address > > column as the primary key means I can always regenerate my primary key > > Warning: don't attach a meaning to a primary key, as it might change And as long as it has cascading updates and deletes it doesn't matter if it changes. As long as it doesn't change into something that collides. This is a religious topic, and there's advantages to both ways. But if the field is and always must be unique and non-null, then there's no reason to not use it as a primary key.