Although configure-based builds correctly define HAVE_LONG_LONG_INT when
appropriate (in both pg_config.h and ecpg_config.h), builds using the MSVC
scripts failed to do so. This currently has no impact on the backend,
since it uses that symbol nowhere; but it does prevent ecpg from
supporting "long long int". Fix that.
Also, adjust Solution.pm so that in the constructed ecpg_config.h file,
the "#if (_MSC_VER > 1200)" covers only the LONG_LONG_INT-related
#defines, not the whole file. AFAICS this was a thinko on somebody's
part: ENABLE_THREAD_SAFETY should always be defined in Windows builds,
and in branches using USE_INTEGER_DATETIMES, the setting of that shouldn't
depend on the compiler version either. If I'm wrong, I imagine the
buildfarm will say so.
Per bug #15080 from Jonathan Allen; issue diagnosed by Michael Meskes
and Andrew Gierth. Back-patch to all supported branches.
Discussion: https://postgr.es/m/
151935568942.1461.
14623890240535309745@wrigleys.postgresql.org
/* Define to 1 if `long int' works and is 64 bits. */
/* #undef HAVE_LONG_INT_64 */
+/* Define to 1 if the system has the type `long long int'. */
+#if (_MSC_VER > 1200)
+#define HAVE_LONG_LONG_INT 1
+#endif
+
/* Define to 1 if `long long int' works and is 64 bits. */
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
|| confess "Could not open ecpg_config.h";
print $o <<EOF;
#if (_MSC_VER > 1200)
+#define HAVE_LONG_LONG_INT 1
#define HAVE_LONG_LONG_INT_64 1
+#endif
#define ENABLE_THREAD_SAFETY 1
EOF
- print $o "#endif\n";
close($o);
}