From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Michael Cronenworth <mike(at)cchtml(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fix Windows socket error checking for MinGW |
Date: | 2013-08-19 14:11:01 |
Message-ID: | 52122775.8050407@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/19/2013 09:50 AM, Michael Cronenworth wrote:
> On 08/18/2013 12:02 PM, Andrew Dunstan wrote:
>> There is a much simpler fix, which is to do these assignments unconditionally in
>> src/port/win32.h. The following small change fixes the problem for me:
>>
> No. Please do not do this.
If you object to a proposal then you need to explain what's wrong with
it. Note that we already do exactly what is proposed here for EAGAIN and
EINTR. In fact there is probably a good argument for doing it for all
these constants.
I tested the patch I made. The environment was a linux hosted
cross-compile, with the latest mingw-64 compiler. Before the patch the
problem complained of was exhibited. After the patch it was not.
>
>> Note that the original patch appears to be not only misguided but wrong, in that
>> it undid a recent important change (commit a099482c) as I read it.
> My patch was created against the latest git checkout as of the date I sent the
> e-mail. If you could provide the full commit ID I could take a look, but it
> seems you don't care about my patch enough I'm not sure you will bother.
>
>
I already gave you a sufficient identifier for the commit. In case
you're not aware, git is quite happy dealing with small commit
identifiers. If you do "git log -1 a099482" you should get the details
you require.
Frankly, we are not going to go through the code littering it with WSA
constants inside #ifdef's without a very good reason.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-08-19 14:16:12 | Re: Should we remove "not fast" promotion at all? |
Previous Message | Charles Sheridan | 2013-08-19 14:09:16 | Re: Automatic Index Creation for Column Types |