Is it too late to add a feature to pg_dump for 6.4??

I just spent most of the day learning pg_dump and modifing it so it
would
dump views also.

This is the first time I have ever contributed any code changes, so I'm
not sure of how to submit it.

The diff's and a readme as a tgz file are attached.

Thanks
Terry Mackintosh <terry@terrym.com>          http://www.terrym.com

of days --- it was emitting stuff like
	REVOKE ALL on 'table' from PUBLIC; GRANT ALL on "table" to
	"Public"; neither of which work.  While I was at it I
cleaned up a few other things:

* \connect commands are issued only in -z mode.  In this way,
reloading a pg_dump script made without -z will generate a simple
database wholly owned by the invoking user, rather than a mishmash
of tables owned by various people but lacking in access rights.
(Analogy: cp versus cp -p.)

* \connect commands are issued just before COPY FROM stdin commands;
without this, reloading a database containing non-world-writable
tables tended to fail because the COPY was not necessarily attempted
as the table owner.

* Redundant \connect commands are suppressed (each one costs a
backend launch, so...).

* Man page updated (-z wasn't ever documented).

The first two items were discussed in a pgsql-hackers thread around
6 May 98 ("An item for the TODO list: pg_dump and multiple table
owners") but no one had bothered to deal with 'em yet.

			regards, tom lane

I've patched pg_dump.c and createdb to add support for password
authentication, using the '-u' switch as in psql. I have updated also the
man pages.

Document pg_dump -z, clean up option list.  Fix problem with libpq handling of field names uppercase code.