!        * themselves, they'll need to check the connection status if we
!        * return an error.

Alfred Perlstein

(it returns error with errno ECHILD upon successful completion of commands).
This fix ignores an error from system() if errno == ECHILD.

add a --with-setproctitle switch to configure that leaves the use of setproctitle()
disabled by default ...

what to do.

think that both sides of indexqual look like index keys.  An example is
create table inside (f1 float8 primary key);
create table outside (g1 float8, g2 float8);
select * from inside,outside where f1 = atan2(g1+1, g2);
ERROR:  ExecInitIndexScan: both left and right ops are rel-vars
(note that failure is potentially platform-dependent).  Solution is a
cleanup I had had in mind to make anyway: functional index keys should
be represented as Var nodes in the fixed indexqual, just like regular
index keys.

it exists) before testing 'using namespace std'.  This is necessary
on some C++ setups where the compiler won't take a 'using' until
you've included a header that mentions namespace std.  (Pretty braindead
if you ask me, but...)

--with-includes) to makefiles for pltcl and plperl, so that these
switches will be used even though we do not want other top-level
CFLAGS.  Ain't it fun trying to support multiple-compiler platforms?

project I am working on (Recall - a distributed, fault-tolerant,
replicated, storage framework @ http://www.fault-tolerant.org).
Recall is written in C++.  I need to include the postgres headers and
there are some problems when including the headers w/C++.

Attached is a patch generated from postgres/src that fixes my problems.
I was hoping to get this into the main source.  It's very small (2k) and
3 files are changed: backend/utils/fmgr/fmgr.c,
backend/utils/Gen_fmgrtab.sh.in, and include/access/tupdesc.h.

In C++, you get a multiply defined symbol because the variable
(FmgrInfo *fmgr_pl_finfo) is defined in the header (the patch moves it
to the .c file).  The other problem in tupdesc.h is the use of typeid
is a problem in c++ (I renamed it to oidtypeid).

Thanks,
Neal Norwitz

some platforms --- and I also see that it is documented as not thread-
safe on HPUX and possibly other platforms.  No good reason not to just
use IPPROTO_TCP constant from <netinet/in.h> instead.

really ought to fix relcache entry construction so that it does not
do so much with CurrentMemoryContext = CacheCxt.  As is, relatively
harmless leaks in either sequential or index scanning translate to
permanent leaks if they occur when called from relcache build.
For the moment, however, the path of least resistance is to repair
all such leaks...

defined then statistics about memory usage of all the global memory
contexts are printed after each commit.

duplicate global declarations, no points for style at all!)

SJIS UDC (NEC selection IBM kanji) support contributed by Eiji Tokuya

terminate the backend that has no frontend anymore.

an index on a table's OID column.  Mea maxima culpa ... but how'd we get
through beta with no one noticing this?

Hiroshi.  ReleaseRelationBuffers now removes rel's buffers from pool,
instead of merely marking them nondirty.  The old code would leave valid
buffers for a deleted relation, which didn't cause any known problems
but can't possibly be a good idea.  There were several places which called
ReleaseRelationBuffers *and* FlushRelationBuffers, which is now
unnecessary; but there were others that did not.  FlushRelationBuffers
no longer emits a warning notice if it finds dirty buffers to flush,
because with the current bufmgr behavior that's not an unexpected
condition.  Also, FlushRelationBuffers will flush out all dirty buffers
for the relation regardless of block number.  This ensures that
pg_upgrade's expectations are met about tuple on-row status bits being
up-to-date on disk.  Lastly, tweak BufTableDelete() to clear the
buffer's tag so that no one can mistake it for being a still-valid
buffer for the page it once held.  Formerly, the buffer would not be
found by buffer hashtable searches after BufTableDelete(), but it would
still be thought to belong to its old relation by the routines that
sequentially scan the shared-buffer array.  Again I know of no bugs
caused by that, but it still can't be a good idea.

PQconnectdb() style connections.