Hi Magnus.
From: "Magnus Hagander" <[EMAIL PROTECTED]>
<snip>
I see the problem now. In my dev kit, there is no error for using
_USE_32BIT_TIME_T on Win64. That's why I got caught up in your patch being
wrong.
Umm,... It is very strange.?_?
C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) as
below...
--
#ifdef _USE_32BIT_TIME_T
#ifdef _WIN64
#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
#undef _USE_32BIT_TIME_T
#endif
#else
#if _INTEGRAL_MAX_BITS < 64
#define _USE_32BIT_TIME_T
#endif
#endif
--
A question there though - do we care about the length of time_t on client
platforms, or should we instead just disable the whole check for the
client? AFAICS we don't expose time_t at all on the client, so why should
we force libpq *clients* to build with 32-bit time_t? Shouldn't we go with
the attached patch instead?
It makes the win64 compile pass for me, but the linker step fails badly with:
libpqdll.def : error LNK2001: unresolved external symbol PQbackendPID
libpqdll.def : error LNK2001: unresolved external symbol PQbinaryTuples
libpqdll.def : error LNK2001: unresolved external symbol PQcancel
libpqdll.def : error LNK2001: unresolved external symbol PQclear
for every export we have. Hiroshi, do you see that as well, or is something
broken
in my win64 environment? I'm running "nmake /f win32.mak CPU=AMD64" to
build per our documentation, is that correct?
Ah yes, however, the 64-bit build environment is created by the command which Microsoft
offers.
As for it, CPU=AMD64 is already defined. Then, I look at a good result after
your patch.
http://winpg.jp/~saito/pg83/WIN32MAK_AMD64_PATCH.txt
Regards,
Hiroshi Saito
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
