Re: sha1, sha2 functions into core?

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sha1, sha2 functions into core?
Date: 2011-08-12 19:14:58
Message-ID: CACMqXC+UKr4=oaGTObhq0MQXa3BcdDbrppfj_tONTNg0wr8sjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... which this approach would create, because digest() isn't restricted
>>> to just those algorithms.  I think it'd be better to just invent two
>>> new functions, which also avoids issues for applications that currently
>>> expect the digest functions to be installed in pgcrypto's schema.
>
>> I would suggest digest() with fixed list of algorithms: md5, sha1, sha2.
>
>> The uncommon/obsolete algorithms that can be used
>> from digest() if compiled with openssl, are not something we
>> need to worry over.  In fact we have never "supported" them,
>> as no testing has been done.
>
> Hmm ... they may be untested by us, but I feel sure that if we remove
> that functionality from pgcrypto, *somebody* is gonna complain.

If you dont want to break digest() but do not want such behaviour in core,
we could go with hash(data, algo) that has fixed number of digests,
but also couple non-cryptographic hashes like crc32, lookup2/3.
This would also fix the problem of people using hashtext() in user code.

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-08-12 19:16:15 Re: VACUUM FULL versus system catalog cache invalidation
Previous Message Tom Lane 2011-08-12 19:14:07 Re: VACUUM FULL versus system catalog cache invalidation