up sleeping processes.

(Sorry, couldn't help it...)

Removed type filename as well, since it's unused and probably useless.
INITDB FORCED, because pg_rewrite columns are now plain text again.

allows fixing problems with operators that expected to be able to
return a NULL, such as the '#' line-segment-intersection operator
that tried to return NULL when the two segments don't intersect.
(See, eg, bug report from 1-Nov-99 on pghackers.)  Fix some other
bugs in passing, such as backwards comparison in path_distance().

updated to new fmgr style.  Deleted hoary old functions for compatibility
with pre-6.1 representations of these datatypes.

I did not force.  I marked numeric as compressable-but-not-move-off-able,
partly to test that storage mode and partly because I've got doubts
that numerics are large enough to need external storage.

 Note that this has changed some of the edge cases for what is accepted
 as a type name and/or column id. Regression test passes, but more
 tweaks may be coming...

the planner may try to generate them as a result of transitivity of the
existing int2-vs-int4 and int4-vs-int8 operators.  In fact, it is now
necessary that mergejoinable cross-datatype operators form closed sets.
Add an opr_sanity regress test to detect missing operators.

eval_const_expressions tries to simplify an SQL function.

for today's snapshot

Andreas

FreeBSD/Intel and DecUX/Alpha machines. The bug appears in postgresql
6.5.3 and 7.0.2. Can someone please review it and apply it to the
source tree?

Sometimes when the postgres connection dies it is necessary to
attempt to reconnect. Calling the pgconnection::Connect method in a
derived class leaks memory because it does not clear the current
connection (if there is one). These patches ensures that any open
connections are closed before attempting to open a new one.

-Michael Richards

of planning.  This should reduce memory requirements for large joins.

discussion on pghackers a few days ago.

to use with a multiple-key index.  Formerly we would only extract clauses
that had to do with the first key of the index, which was correct but
didn't exploit the index fully.

if given a node type it doesn't support.  As is, wrong results from a
mergejoin would go undetected.

nor any OID in the reserved range (1-16383).

failure to MAXALIGN the start of shmem allocable space.  No reports
of trouble here, just compulsive tidiness.

actually, but who could understand it with no comments?  Fix bug
while at it: _bt_orderkeys would try to invoke comparisons on
NULL inputs, given the right sort of redundant quals.

- connect as appropriate user in pg_restore with db connection
- dump owner of rule in pg_dump