DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=YfCPyzi3bmtepNg7+bKT2AnekuQpC3vVnSD+I1DvIjEi2Urbre05A3lqZuCoSgI1YTmkR0DWPyBsH/FI4lW8KfYOjXye+kbGEWa/IlEAN2f8VW3BBzoZDzNofOAMUU+ZByP9UcorVht72ABNAm8Uk7gEdHqET23fzR6NNGLEzow=
Message-ID: <12b7ac1e0607060316ub7b5e21i5e8e3bef2504e02c@mail.gmail.com>
Date: Thu, 6 Jul 2006 22:16:42 +1200
From: "David Clarke" <pigwin32@gmail.com>
To: pgsql-sql@postgresql.org
Subject: Alternative to serial primary key
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I posted a couple of weeks back a question regarding the use of a 100
char column as a primary key and the responses uniformily advised the
use of a serial column. My concern is that the key is effectively
abstract and I want to use the column as a foreign key in other
tables. It occurred to me that if I used a hash function on insert to
generate another column and used that column as the primary key then I
have a value that meets a lot of the requirements for a good key,
including that I can regenerate the exact value from my data,
something that is impossible with a serial id. I also don't have to
index the 100 char column in order to search on the table, I just need
to calculate the hash value and check that against the calculated
column. It does violate the rule that a table shouldn't contain a
column that is calculated from another column in the table but I think
it would still be more effective than a serial id.

Is this a reasonable/normal thing to do? I know postgres contains an
md5() hash function, is this likely to be fast enough to make this an
effective choice? Are there other options? Am I just a noob barking up
the wrong tree? It is getting kind of late and my brain is starting to
hurt.