efficient insertion of large bytea values through the BIND interface.

dropped.  The simplest fix for INSERT/UPDATE cases turns out to be for
preptlist.c to insert NULLs of a known-good type (I used INT4) rather
than making them match the deleted column's type.  Since the representation
of NULL is actually datatype-independent, this should work fine.
I also re-reverted the patch to disable the use_physical_tlist optimization
in the presence of dropped columns.  It still doesn't look worth the
trouble to be smarter, if there are no other bugs to fix.
Added a regression test to catch future problems in this area.

more cases than I thought, so ExecTypeFromTL() will have to be fixed
anyway.

where the table contains dropped columns.  If the columns are dropped,
then their types may be gone as well, which causes ExecTypeFromTL() to
fail if the dropped columns appear in a plan node's tlist.  This could
be worked around but I don't think the optimization is valuable enough
to be worth the trouble.

detected during buffer dump to be labeled with the buffer location.
For example, if a page LSN is clobbered, we now produce something like
ERROR:  XLogFlush: request 2C000000/8468EC8 is not satisfied --- flushed only
to 0/8468EF0
CONTEXT:  writing block 0 of relation 428946/566240
whereas before there was no convenient way to find out which page had
been trashed.

instead of calling it a 'server process'.

dead xlog segments are not considered part of a critical section.  It is
not necessary to force a database-wide panic if we get a failure in these
operations.  Per recent trouble reports.

Cleanup new crypt() source code.

for rint prototype.

the folly of not passing element type to typsend/typreceive, so fix that.

so that COPY BINARY regression test passes.

fastpath.c had better check for strict functions.

messages.  Binary I/O is now up and working, but only for a small set
of datatypes (integers, text, bytea).

testing purposes.

Keep SRA copyright on file because it contains BSD license clause.

yet, but they're there.  Also some editorial work on CREATE TYPE reference
page.

as speaking the one true 3.0 protocol.

handle multiple 'formats' for data I/O.  Restructure CommandDest and
DestReceiver stuff one more time (it's finally starting to look a bit
clean though).  Code now matches latest 3.0 protocol document as far
as message formats go --- but there is no support for binary I/O yet.

Allow backends to attached to specified shared memory address.

terminating zero byte in StartupMessage, docs didn't mention it.

external representation of binary data.

first version of the 3.0 protocol that can be considered non-draft.

than WIN32.

the connection when appropriate.
This checkin also adds the type map for jdbc3, however currently it is
identical to the jdbc2 mapping.

 Modified Files:
 	jdbc/org/postgresql/core/BaseStatement.java
 	jdbc/org/postgresql/core/QueryExecutor.java
 	jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java

fork/exec.

of Describe on a prepared statement.  This was in the original 3.0
protocol proposal, but I took it out for reasons that seemed good at
the time.  Put it back per yesterday's pghackers discussion.