Greg Sabino Mullane wrote:
4) We're also encouraging the use of md5() by making it the only option. Yes, we can talk about why people *shouldn't* use it for this purpose or that, but they will.
There is always the Java route - internal classes have package-scope constructors to specifically prevent them from being accidentally used (and relied on).
I prefer the "let them use it, but warn them not to have expectations" route, which is what PostgreSQL is doing today. The above is not a legitimate reason to provide additional functions in the core.
5) It seems unwise to go through the trouble of just adding sha1(), when we could easily add some better hashes, which has the nice side effect of making us stand out more and push the envelope, rather than play follow the leader, as was mentioned at PGCon East
This presumes that better hashes truly exist. It is basic math to show that all hashes will include collisions. Ignoring the possibility that one hash has theoretical better distribution for real documents, the real "benefit" of SHA-1 over MD5, is that it has more bits. The "ultimate" solution here, is to store the original using the "full copy" hash technique, with 0 chance of collision. This extreme defeats the purpose of a hash to start with.
Why does PostgreSQL need something better than md5 as part of core? Bragging rights?
Cheers, mark -- Mark Mielke <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
