| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Kenneth Marshall <ktm(at)rice(dot)edu> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Sehrope Sarkuni <sehrope(at)jackdb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add SQL function for SHA1 |
| Date: | 2021-01-26 04:27:28 |
| Message-ID: | 20210126042728.GC18075@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 25, 2021 at 10:23:30PM -0600, Kenneth Marshall wrote:
> On Tue, Jan 26, 2021 at 01:06:29PM +0900, Michael Paquier wrote:
> > On Mon, Jan 25, 2021 at 10:42:25PM -0500, Sehrope Sarkuni wrote:
> > > +1 to adding a SHA1 SQL function. Even if it's deprecated, there's plenty
> > > of historical usage that I can see it being useful.
> >
> > Let's wait for more opinions to see if we agree that this addition is
> > helpful or not. Even if this is not added, I think that there is
> > still value in refactoring the code anyway for the SHA-2 functions.
> >
>
> +1 I know that it has been deprecated, but it can be very useful when
> working with data from pre-deprecation. :) It is annoying to have to
> resort to plperl or plpython because it is not available. The lack or
> orthogonality is painful.
Yes, I think having SHA1 makes sense --- there are probably still valid
uses for it.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2021-01-26 04:38:32 | Re: patch: reduce overhead of execution of CALL statement in no atomic mode from PL/pgSQL |
| Previous Message | Kenneth Marshall | 2021-01-26 04:23:30 | Re: Add SQL function for SHA1 |