On Fri, Sep 02, 2011 at 02:05:45PM -0500, ktm@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. reedstrm@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
