On Fri, Sep 02, 2011 at 02:05:45PM -0500, k...@rice.edu wrote: > On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote: > > On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote: > > > Hmm, this thread seems to have petered out without a conclusion. Just > > > wanted to comment that there _are_ non-password storage uses for these > > > digests: I use them in a context of storing large files in a bytea > > > column, as a means to doing data deduplication, and avoiding pushing > > > files from clients to server and back. > > > > But I suppose you don't need the hash function in the database system > > for that. > > > > It is very useful to have the same hash function used internally by > PostgreSQL exposed externally. I know you can get the code and add an > equivalent one of your own... > Thanks for the support Ken, but Peter's right: the only backend use in my particular case is to let the backend do the hash calc during bulk loads: in the production code path, having the hash in two places doesn't save any work, since the client code has to calculate the hash in order to test for its existence in the backend. I suppose if the network cost was negligable, I could just push the files anyway, and have a before-insert trigger calculate the hash and do the dedup: then it'd be hidden in the backend completely. But as is, I can do all the work in the client.
Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer & Admin, Research Scientist phone: 713-348-6166 Connexions http://cnx.org fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
