diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-02-27 16:46:52 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-02-27 16:46:52 -0500 |
| commit | f171cbe0d90ef91ed8ae69888cece03d1f9e5c8d (patch) | |
| tree | 588f055d1fee9975e5e149ab6689a5a99073f328 /src/backend/access/gist/gistvacuum.c | |
| parent | 85be69154a1edc9abd9e1557ad7b2f09c0ad88bc (diff) | |
| download | postgresql-f171cbe0d90ef91ed8ae69888cece03d1f9e5c8d.tar.gz postgresql-f171cbe0d90ef91ed8ae69888cece03d1f9e5c8d.zip | |
Fix up ecpg's configuration so it handles "long long int" in MSVC builds.
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
Diffstat (limited to 'src/backend/access/gist/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions