From: | Sehrope Sarkuni <sehrope(at)jackdb(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Noah Misch <noah(at)leadboat(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add SQL function for SHA1 |
Date: | 2021-01-27 02:53:52 |
Message-ID: | CAH7T-aq1bPfeQY+Bg9-POc62EgfGKeBZ7QPk97iDWv0DeYv9Aw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 26, 2021 at 8:53 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Jan 26, 2021 at 10:38:43AM +0100, Daniel Gustafsson wrote:
> > Agreed, and pgcrypto already allows for using sha1.
> >
> > It seems like any legitimate need for sha1 could be better served by an
> > extension rather than supplying it in-core.
>
> Both of you telling the same thing is enough for me to discard this
> new stuff. I'd like to refactor the code anyway as that's a nice
> cleanup, and this would have the advantage to make people look at
> cryptohashfuncs.c if introducing a new type. After sleeping about it,
> I think that I would just make MD5 and SHA1 issue an elog(ERROR) if
> the internal routine is taken in those cases, like in the attached.
>
The refactor patch looks good. It builds and passes make check.
Thanks for the enum explanation too.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2021-01-27 03:11:08 | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
Previous Message | Kyotaro Horiguchi | 2021-01-27 02:35:00 | Re: archive status ".ready" files may be created too early |