From: | Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Improve error handling of HMAC computations and SCRAM |
Date: | 2022-01-11 07:50:50 |
Message-ID: | 066c0624-fbb7-a025-afd6-d54683a96947@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 11.01.2022 07:56, Michael Paquier wrote:
> Thoughts?
A few comments after a quick glance...
+ * Returns a static string providing errors about an error that happened
"errors about an error" looks odd.
+static const char *
+SSLerrmessage(unsigned long ecode)
+{
+ if (ecode == 0)
+ return NULL;
+
+ /*
+ * This may return NULL, but we would fall back to a default error path if
+ * that were the case.
+ */
+ return ERR_reason_error_string(ecode);
+}
We already have SSLerrmessage elsewhere and it's documented to never
return NULL. I find that confusing.
If I have two distinct pg_hmac_ctx's, are their errreason's idependent
from one another or do they really point to the same static buffer?
Regards,
--
Sergey Shinderuk https://postgrespro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-01-11 07:51:19 | Re: Windows crash / abort handling |
Previous Message | Michael Paquier | 2022-01-11 07:50:23 | Re: pg_dump/restore --no-tableam |