Re: MD5 aggregate
От | Andrew Dunstan |
---|---|
Тема | Re: MD5 aggregate |
Дата | |
Msg-id | 51BB21A5.3060300@dunslane.net обсуждение исходный текст |
Ответ на | Re: MD5 aggregate (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: MD5 aggregate
|
Список | pgsql-hackers |
On 06/14/2013 09:40 AM, Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> Marko Kreen <markokr@gmail.com> writes: >>> On Thu, Jun 13, 2013 at 12:35 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: >>>> Attached is a patch implementing a new aggregate function md5_agg() to >>>> compute the aggregate MD5 sum across a number of rows. >>> It's more efficient to calculate per-row md5, and then sum() them. >>> This avoids the need for ORDER BY. >> Good point. The aggregate md5 function also fails to distinguish the >> case where we have 'xyzzy' followed by 'xyz' in two adjacent rows >> from the case where they contain 'xyz' followed by 'zyxyz'. >> >> Now, as against that, you lose any sensitivity to the ordering of the >> values. >> >> Personally I'd be a bit inclined to xor the per-row md5's rather than >> sum them, but that's a small matter. > Where I'd take this is actually in a completely different direction.. > I'd like the aggregate to be able to match the results of running the > 'md5sum' unix utility on a file that's been COPY'd out. Yes, that means > we'd need a way to get back "what would this row look like if it was > sent through COPY with these parameters", but I've long wanted that > also. > > No, no clue about how to put all that together. Yes, having this would > be better than nothing, so I'm still for adding this even if we can't > make it match COPY output. :) > > I'd rather go the other way, processing the records without having to process them otherwise at all. Turning things into text must slow things down, surely. cheers andrew
В списке pgsql-hackers по дате отправления: