From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> |
Cc: | 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:57:19 |
Message-ID: | Yd04X0JHdfLgKVC+@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 11, 2022 at 10:50:50AM +0300, Sergey Shinderuk wrote:
> A few comments after a quick glance...
Thanks!
> + * Returns a static string providing errors about an error that happened
>
> "errors about an error" looks odd.
Sure, that could be reworded. What about "providing details about an
error"?
> We already have SSLerrmessage elsewhere and it's documented to never return
> NULL. I find that confusing.
This name is chosen on purpose. There could be some refactoring done
with those things.
> 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?
Each errreason could be different, as each computation could fail for
a different reason. If they fail for the same reason, they would
point to the same error context strings.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | tanghy.fnst@fujitsu.com | 2022-01-11 08:02:19 | RE: row filtering for logical replication |
Previous Message | Andres Freund | 2022-01-11 07:51:19 | Re: Windows crash / abort handling |