to an undecorated relation name (cf. example from Ed Loehr, 5/25/00).

since-closed file descriptors...

subsequent I/O attempts fail cleanly.  I'm speculating about failure
scenarios in which we do pq_close, then something in a proc_exit routine
opens a file (re-using that kernel FD number), then something else
fails and tries to write an elog message to the frontend ... message
ends up in opened file, oops.  No known examples of this but it seems
like a potential hole.

the oper field should be a valid Node structure so it can be dumped by
outfuncs.c without risk of coredump.  (We had been using a raw pointer
to character string, which surely is NOT a valid Node.)  This doesn't
cause any backwards compatibility problems for stored rules, since
raw unanalyzed parsetrees are never stored.

*last*, after all updating of system catalogs.  In old code, an error
detected during TypeRename left the relation hosed.  Also, add a call
to flush the relation's relcache entry, rather than trusting to shared
cache invalidation to flush it for us.

relation being dropped.

!        * 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.