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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
