Per discussion with Magnus Hagander.

or a Var that references a subquery output.

MULTIBYTE support is not compiled (you just can't set them to anything
but SQL_ASCII).  This should reduce interoperability problems between
MB-enabled clients and non-MB-enabled servers.

support is not present.  This allows a non-MB server to load a pg_dumpall
script produced by an MB-enabled server, so long as only ASCII encoding
was used.

the -l options.  (This was not the case when using the  OpenSSL or Kerberos
options.)  Also make sure that shared library links get to see all the -L
options.  Get Kerberos 5 support to compile on Redhat 7.0.  Add OpenSSL and
-lsocket (if used/found) to libpq link.

I modified the current ODBC driver for

* referential integrity error reporting,
* SELECT in transactions and
* disabling autocommit.

I tested these changes with Borland C++ Builder -> ODBCExpress ->
WinODBC driver (DLL) -> Postgres 7.0beta1 and Borland C++ Builder -> BDE ->
WinODBC driver (DLL) -> Postgres 7.0beta1. The patch is based on snapshot of
22th April (I don't think that someone has modified it since that: Byron
hasn't gave any sign of living for about a month and I didn't find any
comments about the ODBC driver on the list).

Dump template db in dumpall

for input, not just before.

Just like queries, doing nothing is better than possibly getting weird
error messages.  Also, improve comments.

operator to '#' for consistency.  Parser still needs work.

'AbortTransaction and not in in-progress state' when client disconnects
just after an error.  Notice seems pretty harmless, so I'm not going
to worry about back-patching this into 7.0.* ...

source).  Adjust resultmap accordingly and fix some other regexps.

definition later...)

messed up and we end up with the comments from included files in the output
"configure".

latest fixes make it safe or not, but we won't find out if no one builds
it, eh?

Devel::PPPort instead.  Thanks to Gilles Darold for doing the legwork.

Fix for endian bug in TAR output
Nicer error messages in pg_dump

once per distinct LO, not once per pg_largeobject tuple.

as full as possible, seems better to use a tuple size around BLCKSZ/4
so that less space is wasted when a LO tuple is updated.  Also, this
lets us use a logical page size that's an exact power of two, avoiding
partial-page writes when client is sending us stuff in power-of-2
buffer chunks.

This used to make some sense under the old implementation, but now an
open LO is pretty darn cheap, so why restrict it?

kibitzing from Tom Lane.  Large objects are now all stored in a single
system relation "pg_largeobject" --- no more xinv or xinx files, no more
relkind 'l'.  This should offer substantial performance improvement for
large numbers of LOs, since there won't be directory bloat anymore.
It'll also fix problems like running out of locktable space when you
access thousands of LOs in one transaction.
Also clean up cruft in read/write routines.  LOs with "holes" in them
(never-written byte ranges) now work just like Unix files with holes do:
a hole reads as zeroes but doesn't occupy storage space.
INITDB forced!

testlo.c, except it's even skimpier on error checking :-(

source, due to addition of header overhead), store it as plain data
rather than pseudo-compressed data.  This saves a few microseconds when
reading it out, but much more importantly guarantees that the toaster
won't actually expand tuples that contain incompressible data.  That's
essential to avoid 'Tuple too big' failures with large objects.