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-11 12:10:27
Message-ID: CACMqXCJjsH1=hE1mSnY3=ekMOsqY8NqhMnxeep8fPrG9wKWacQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> I would like to see whether there is support for adding sha1 and sha2
>> functions into the core.
>
> I can't get excited about that, but could put up with it as long as
> there wasn't scope creep ...
>
>> One thing that might be reasonable would be to move the digest()
>> functions
>>     digest(data text, type text) returns bytea
>>     digest(data bytea, type text) returns bytea
>> from pgcrypto into core,
>
> ... 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.

Then we could also add hexdigest() which would fix whole bytea/hex
confusion without bloating pg_proc.

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message pasman pasmański 2011-08-11 12:58:32 compiling 9.2 : WinXp+mingw
Previous Message Heikki Linnakangas 2011-08-11 10:28:58 Re: WIP: Fast GiST index build