On Fri, 2022-01-14 at 10:49 +0900, Michael Paquier wrote:
> On Thu, Jan 13, 2022 at 02:52:12PM -0500, Tom Lane wrote:
> > Probably none of this should have been back-patched --- the issues
> > are not so large that they require a risk of breaking things in
> > the back branches.
>
> Agreed, that's
On Thu, Jan 13, 2022 at 02:52:12PM -0500, Tom Lane wrote:
> Probably none of this should have been back-patched --- the issues
> are not so large that they require a risk of breaking things in
> the back branches.
Agreed, that's not worth breaking things in v14, so I'll go and revert
this stuff in
Laurenz Albe writes:
> On Tue, 2022-01-11 at 00:56 +, Michael Paquier wrote:
>> Improve error handling of cryptohash computations
> This commit changes the signature of the exported "pg_md5_hash" function,
> which breaks my extension that uses this function.
> Is there no way to avoid this AP
On Tue, 2022-01-11 at 00:56 +, Michael Paquier wrote:
> Improve error handling of cryptohash computations
This commit changes the signature of the exported "pg_md5_hash" function,
which breaks my extension that uses this function.
Is there no way to avoid this API break in the back branches?
Improve error handling of cryptohash computations
The existing cryptohash facility was causing problems in some code paths
related to MD5 (frontend and backend) that relied on the fact that the
only type of error that could happen would be an OOM, as the MD5
implementation used in PostgreSQL ~13 (
Improve error handling of cryptohash computations
The existing cryptohash facility was causing problems in some code paths
related to MD5 (frontend and backend) that relied on the fact that the
only type of error that could happen would be an OOM, as the MD5
implementation used in PostgreSQL ~13 (
