Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor
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
Log Message:
---
Accomodate oddities in at least some versions of File::Copy.
Modified Files:
--
client-code:
run_build.pl (r1.110 -> r1.111)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/run_build.pl?r1=1.110&r2=1.111)
client-cod
Log Message:
---
Split the LDFLAGS make variable into two parts: LDFLAGS is now used for
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 l
Log Message:
---
Fix a few single-file (MODULES, not MODULE_big) contrib makefiles that were
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 Makefile
Log Message:
---
Make sure LDFLAGS come before LIBS when linking contrib programs.
Solaris, at least, seems to be sensitive to the relative order of -L
and -l switches, so this is needed. Per buildfarm results.
Modified Files:
--
pgsql/src/makefiles:
pgxs.mk (r1.20
Log Message:
---
Dept. of third thoughts: PG_LIBS may contain a -L switch, so it had better
stay in front of LDFLAGS.
Modified Files:
--
pgsql/src/makefiles:
pgxs.mk (r1.21 -> r1.22)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/makefiles/pgxs.mk?r1=1
Log Message:
---
Allow for LDFLAGS_SL already having a value in Makefile.aix.
Per buildfarm results.
Modified Files:
--
pgsql/src/makefiles:
Makefile.aix (r1.31 -> r1.32)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/makefiles/Makefile.aix?r1=1.31&r2=
Log Message:
---
Still more third thoughts: when linking shared libraries, LDFLAGS probably
needs to appear before anything placed in SHLIB_LINK. This is because
SHLIB_LINK is typically a subset of LIBS, and LIBS has to appear after
LDFLAGS on platforms that are sensitive to the relative o
14 matches
Mail list logo
