> On 22 Apr 2022, at 19:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Consuming all (both) errors and creating a concatenated string seems overkill
>> as it would alter the API from a const error string to something that needs
>> freeing etc (also, very few OpenSSL consumers actually drain the queue, OpenSSL
>> themselves don't). Skimming the OpenSSL code I was unable to find another
>> example of two errors generated. The attached calls ERR_clear_error() as how
>> we do in libpq in order to avoid consuming earlier errors.
>
> This seems quite messy. How would clearing the queue *before* creating
> the object improve matters?
We know there won't be any leftovers which would make us display the wrong
message.
> It seems like that solution means you're leaving an extra error in the queue to
> break unrelated code. Wouldn't it be better to clear after grabbing the error?
> (Or maybe do both.)
That's a very good point, doing it in both ends of the operation is better
here.
> Also, a comment seems advisable.
Agreed.
--
Daniel Gustafsson https://vmware.com/