Thom Brown wrote: > This would preferrably not resort to trying to generate the ID, then > checking for a clash, and if there is one, do it again, although that could > do as I can't think of how the ideal solution of a ID hashing algorithm > would be possible. As suggested upthread, this function: http://wiki.postgresql.org/wiki/Pseudo_encrypt can be used to generate integers without collision. But the output range is 32 bits, and expressing 2^32 values with 32 letters produces strings of 7 characters, not 5. I don't think that the strings can be shortened in a post-processing stage without producing the collisions that were to be avoided in the first place. However, changing the function to reduce its output range is possible. Going down from 32 bits to 30 has been discussed already: http://archives.postgresql.org/pgsql-general/2009-07/msg00194.php 2^30 happens to be exactly equal to 32^6, so this modified version would produce exactly all the possible strings of 6 characters out of 32 without any collision. If you really want no more than 5 characters, you'd need to go down to 24 bits, but then the number of different outputs would be only about 16 millions. Best regards, -- Daniel PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
