1. 03 Mar, 2018 6 commits
  2. 02 Mar, 2018 11 commits
  3. 01 Mar, 2018 11 commits
  4. 28 Feb, 2018 10 commits
  5. 27 Feb, 2018 2 commits
    • Tom Lane's avatar
      Fix up ecpg's configuration so it handles "long long int" in MSVC builds. · 51057fea
      Tom Lane authored
      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
      51057fea
    • Tom Lane's avatar
      Use the correct tuplestore read pointer in a NamedTuplestoreScan. · e98a4de7
      Tom Lane authored
      Tom Kazimiers reported that transition tables don't work correctly when
      they are scanned by more than one executor node.  That's because commit
      18ce3a4a allocated separate read pointers for each executor node, as it
      must, but failed to make them active at the appropriate times.  Repair.
      
      Thomas Munro
      
      Discussion: https://postgr.es/m/20180224034748.bixarv6632vbxgeb%40dewberry.localdomain
      e98a4de7