Christian Ullrich writes:
> * Tom Lane wrote:
>> Oh? Then we should not need that one (the /D switch in win32.mak) at all.
>> Should we just remove it?
> We have both confirmed several times that nothing depends on it. I think it
> can go.
Done.
regards, tom lane
--
Christian Ullrich writes:
> * Tom Lane wrote:
>> Hm, my grep found another one ...
> Oh, sorry. I saw that one, but thought it was intentional because _WIN64
> is defined automatically anyway.
Oh? Then we should not need that one (the /D switch in win32.mak) at all.
Should we just remove it?
* From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Christian Ullrich writes:
> > * Tom Lane wrote:
> >> Hm, my grep found another one ...
>
> > Oh, sorry. I saw that one, but thought it was intentional because _WIN64
> > is defined automatically anyway.
>
> Oh? Then we should not need that one (t
* Tom Lane wrote:
Christian Ullrich writes:
According to git grep, this is the only place where WIN64 is used
without the leading underscore.
Hm, my grep found another one ...
Oh, sorry. I saw that one, but thought it was intentional because _WIN64
is defined automatically anyway.
--
Christian Ullrich writes:
> Here is a one-line patch to fix a wrong preprocessor condition in
> pg_regress, found because the VS 2015 compiler warns on the cast in the
> 32-bit branch where apparently earlier versions did not.
Pushed, thanks.
> According to git grep, this is the only place whe
Here is a one-line patch to fix a wrong preprocessor condition in
pg_regress, found because the VS 2015 compiler warns on the cast in the
32-bit branch where apparently earlier versions did not.
According to git grep, this is the only place where WIN64 is used
without the leading underscore.
