On Tue, Jan 26, 2021 at 09:53:52PM -0500, Sehrope Sarkuni wrote:
> The refactor patch looks good. It builds and passes make check.
Thanks for double-checking! The refactoring has been just done as of
f854c69.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jan 26, 2021 at 8:53 PM Michael Paquier 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
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
> On 26 Jan 2021, at 04:28, Noah Misch wrote:
>
> On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
>> SHA-1 is now an option available for cryptohashes, and like the
>> existing set of functions of SHA-2, I don't really see a reason why we
>> should not have a SQL function for
On Mon, Jan 25, 2021 at 11:27:28PM -0500, Bruce Momjian wrote:
> On Mon, Jan 25, 2021 at 10:23:30PM -0600, Kenneth Marshall wrote:
>> +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
On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
> Hi all,
>
> SHA-1 is now an option available for cryptohashes, and like the
> existing set of functions of SHA-2, I don't really see a reason why we
> should not have a SQL function for SHA1. Attached is a patch doing
> that.
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
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
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
+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.
Either way, the rest of the refactor can be improved a bit to perform a
single palloc() and remove the memcpy(). Attached is a diff for
cryptohashfuncs.c that does that by
On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
> SHA-1 is now an option available for cryptohashes, and like the
> existing set of functions of SHA-2, I don't really see a reason why we
> should not have a SQL function for SHA1.
NIST deprecated SHA1 over ten years ago. It's too
Hi all,
SHA-1 is now an option available for cryptohashes, and like the
existing set of functions of SHA-2, I don't really see a reason why we
should not have a SQL function for SHA1. Attached is a patch doing
that.
The same code pattern was repeated 4 times on HEAD for the SHA-2
functions for
12 matches
Mail list logo
