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
