1. 08 Jul, 2010 8 commits
  2. 07 Jul, 2010 2 commits
  3. 06 Jul, 2010 10 commits
  4. 05 Jul, 2010 5 commits
    • Tom Lane's avatar
      Dept. of third thoughts: PG_LIBS may contain a -L switch, so it had better · f6af1435
      Tom Lane authored
      stay in front of LDFLAGS.
      f6af1435
    • Tom Lane's avatar
      Make sure LDFLAGS come before LIBS when linking contrib programs. · bdf00543
      Tom Lane authored
      Solaris, at least, seems to be sensitive to the relative order of -L
      and -l switches, so this is needed.  Per buildfarm results.
      bdf00543
    • Tom Lane's avatar
      Fix a few single-file (MODULES, not MODULE_big) contrib makefiles that were · f9e9da66
      Tom Lane authored
      supposing that they should set SHLIB_LINK rather than LDFLAGS_SL.  Since these
      don't go through Makefile.shlib that was a no-op on most platforms.  Also
      regularize the few platform-specific Makefiles that did pay attention to
      SHLIB_LINK: it seems that the real value of that is to pull in BE_DLLLIBS,
      so do that instead.  Per buildfarm failures on cygwin.
      f9e9da66
    • Tom Lane's avatar
      Split the LDFLAGS make variable into two parts: LDFLAGS is now used for · 291a9577
      Tom Lane authored
      linking both executables and shared libraries, and we add on LDFLAGS_EX when
      linking executables or LDFLAGS_SL when linking shared libraries.  This
      provides a significantly cleaner way of dealing with link-time switches than
      the former behavior.  Also, make sure that the various platform-specific
      %.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that
      before.  (I did not add these variables for the platforms that invoke $(LD)
      directly, however.  It's not clear if we can do that safely, since for the
      most part we assume these variables use CC command-line syntax.)
      
      Per gripe from Aaron Swenson and subsequent investigation.
      291a9577
    • Heikki Linnakangas's avatar
      The previous fix in CVS HEAD and 8.4 for handling the case where a cursor · eb81b650
      Heikki Linnakangas authored
      being used in a PL/pgSQL FOR loop is closed was inadequate, as Tom Lane
      pointed out. The bug affects FOR statement variants too, because you can
      close an implicitly created cursor too by guessing the "<unnamed portal X>"
      name created for it.
      
      To fix that, "pin" the portal to prevent it from being dropped while it's
      being used in a PL/pgSQL FOR loop. Backpatch all the way to 7.4 which is
      the oldest supported version.
      eb81b650
  5. 04 Jul, 2010 2 commits
  6. 03 Jul, 2010 11 commits
  7. 02 Jul, 2010 2 commits