From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
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 16:47:49 |
Message-ID: | 51CC6CB5.4000705@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. ;-)
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2013-06-27 16:51:43 | Re: Group Commits Vs WAL Writes |
Previous Message | Tom Lane | 2013-06-27 16:42:47 | Re: PQConnectPoll, connect(2), EWOULDBLOCK and somaxconn |