Michael Paquier <mich...@paquier.xyz> writes:
> On Wed, Nov 03, 2021 at 11:45:26PM -0400, Tom Lane wrote:
>> Yeah, I noted the comment about WIN32_LEAN_AND_MEAN in the
>> stackoverflow thread too ... but as you say, it seems like
>> that should make the problem less probable not more so.
>> Still, it's hard to think of any other relevant change.
> Yeah, I don't see how this could be linked to WIN32_LEAN_AND_MEAN.
According to that stackoverflow thread, the unwanted #define of
X509_NAME comes from <wincrypt.h>, and WIN32_LEAN_AND_MEAN
prevents that from being immediately included by <windows.h>.
The rough idea I have is that prior to 8162464a2, we sucked in
that #define during postgres.h and then OpenSSL's headers were
able to undo it. After 8162464a2, we don't read <wincrypt.h>
during postgres.h, but some *other* header that be-secure-openssl.c
is including after the OpenSSL headers is pulling it in, so that
by the time we get to the body of the file the unwanted #define
is active.
I don't have either the resources or the interest to track down
exactly where that happens; my thought was just to make
be-secure-openssl.c's inclusions look more like fe-secure-openssl.c.
But, if you'd like to pursue the details, feel free.
regards, tom lane
