Re: MD5 aggregate

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, david(at)fetter(dot)org
Subject: Re: MD5 aggregate
Date: 2013-06-27 23:10:32
Message-ID: CAEZATCVCWObMN4Mtu1GktZXBt1L3hfSAeE17fYiLP64KxFusNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 June 2013 17:47, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 6/27/13 4:19 AM, Dean Rasheed wrote:
>> I'd say there are clearly people who want it, and the nature of some
>> of those answers suggests to me that we ought to have a better answer
>> in core.
>
> It's not clear what these people wanted this functionality for. They
> all wanted to analyze a table to compare with another table (or the same
> table later). Either, they wanted this to detect data changes, in which
> case the right tool is a checksum, not a cryptographic hash. We already
> have several checksum implementations in core, so we could expose on of
> them. Or they wanted this to protect their data from tampering, in
> which case the right tool is a cryptographic hash, but Noah argues that
> a sum of MD5 hashes is not cryptographically sound. (And in any case,
> we don't put cryptographic functionality into the core.)
>
> The reason md5_agg is proposed here and in all those cited posts is
> presumably because the md5() function was already there anyway. The the
> md5() function is there because the md5 code was already there anyway
> because of the authentication. Let's not add higher-order
> already-there-anyway code. ;-)
>

OK fair enough. It's looking like there are more people who don't want
md5_agg() in core, or want something different, than who do want it.
Also, if we're taking the view that the existing md5() function is
only for hashing passwords, then it's probably not worth trying to
optimise it.

At this stage it's probably best to mark this as returned with
feedback, and I'll consider the options for rewriting it, but not
during this commitfest.

Regards,
Dean

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-06-27 23:37:42 Re: MemoryContextAllocHuge(): selectively bypassing MaxAllocSize
Previous Message Kevin Grittner 2013-06-27 22:55:02 Re: Add more regression tests for dbcommands