> On 22 Apr 2022, at 19:01, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniel Gustafsson <dan...@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/
