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

These weren't really "man page"-ish anyway, and I've verified that
 all information in them has moved to the newer sources.

From: Massimo Dal Zotto <dz@cs.unitn.it>

no longer returns buffer pointer, can be gotten from scan;
	descriptor; bootstrap can create multi-key indexes;
pg_procname index now is multi-key index; oidint2, oidint4, oidname
are gone (must be removed from regression tests); use System Cache
rather than sequential scan in many places; heap_modifytuple no
longer takes buffer parameter; remove unused buffer parameter in
a few other functions; oid8 is not index-able; remove some use of
single-character variable names; cleanup Buffer variables usage
and scan descriptor looping; cleaned up allocation and freeing of
tuples; 18k lines of diff;

 removed from the man pages and put into the new sgml docs.

pgbuiltin.3 is obsolete for sure, and libpq.3 can become so since the
 size and scope of this man page is not appropriate in a man page format.

The "Oracle compatibility" page should have always been in with functions
 anyway. The BKI information is not really appropriate for a man page.

The attached patch implements some changes that were discussed a
couple weeks ago on the hackers and interfaces lists:

1. When the backend sends a NOTICE message and closes the connection
   (typically, because it was told to by the postmaster after
   another backend coredumped), libpq will now print the notice
   and close the connection cleanly.  Formerly, the frontend app
   would usually terminate ungracefully due to a SIGPIPE.  (I am
   not sure if 6.3.2 behaved that way, but the current cvs sources
   do...)

2. libpq's various printouts to stderr are now fed through a single
   "notice processor" routine, which can be overridden by the
   application to direct notices someplace else.  This should ease
   porting libpq to Windows.

I also noticed and fixed a problem in PQprint: when sending output
to a pager subprocess, it would disable SIGPIPE in case the pager
terminates early (this is good) --- but afterwards it reset SIGPIPE
to SIG_DFL, rather than restoring the application's prior setting
(bad).

			regards, tom lane

the postmaster log file.

manual pages.

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

From: Tom Lane <tgl@sss.pgh.pa.us>

Attached are diffs (from current cvs sources) to bring libpq.sgml
and libpq.3 up to date.

It appears that at various times in the past, people have made edits to
one or the other of these files but not both.  I propagated some changes
from each into the other, but I don't think I caught every
inconsistency.  It'd be real nice if the man pages could be
automatically generated from the SGML...

From: Tom Lane <tgl@sss.pgh.pa.us>

Making PQrequestCancel safe to call in a signal handler turned out to be
much easier than I feared.  So here are the diffs.

Some notes:
  * I modified the postmaster's packet "iodone" callback interface to allow
    the callback routine to return a continue-or-drop-connection return
    code; this was necessary to allow the connection to be closed after
    receiving a Cancel, rather than proceeding to launch a new backend...
    Being a neatnik, I also made the iodone proc have a typechecked
    parameter list.
  * I deleted all code I could find that had to do with OOB.
  * I made some edits to ensure that all signals mentioned in the code
    are referred to symbolically not by numbers ("SIGUSR2" not "2").
    I think Bruce may have already done at least some of the same edits;
    I hope that merging these patches is not too painful.