Re: [HACKERS] Preprocessor condition fix

2016-04-12 Thread Tom Lane
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.

Re: [HACKERS] Preprocessor condition fix

2016-04-12 Thread 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.

Re: [HACKERS] Preprocessor condition fix

2016-04-12 Thread Christian Ullrich
* 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

Re: [HACKERS] Preprocessor condition fix

2016-04-12 Thread Christian Ullrich
* 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

Re: [HACKERS] Preprocessor condition fix

2016-04-11 Thread Tom Lane
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,