pg_dumpall should permit quiet operation

Without showing the database being dumped, the entire output of
pg_dumpall seems pretty useless so you may as well pipe the whole output
to /dev/null. I don't think a quiet feature for pg_dumpall has enough
use for ordinary users. Sorry.

---------------------------------------------------------------------------

Neil T. Spring wrote:

pg_dumpall now prints status messages; I find them to be a
nuisance, and the patch below implements a --quiet option,
though not necessarily well.

thanks,
-neil

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name : Neil Spring
Your email address : nspring@cs.washington.edu

System Configuration
---------------------
Architecture (example: Intel Pentium) : PIII dual 1GHz

Operating System (example: Linux 2.0.26 ELF) : Debian Woody / 2.4.18

PostgreSQL version (example: PostgreSQL-7.2.1): PostgreSQL-7.2.1

Compiler used (example: gcc 2.95.2) : 2.95.4

Please enter a FULL description of your problem:
------------------------------------------------

pg_dumpall now prints status messages to stderr, which makes
it less suitable for a nightly cron job to backup the
database. I either get nightly useless mail, or redirect
stderr so that I don't know about errors. pg_dumpall
should not print those messages, or at least support
a --quiet option.

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

type "pg_dumpall > x". watch informational messages appear.

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

patch to pg_dumpall.sh follows. A patch to pg_dumpall.1 is
straightforward, assuming this is the way to deal with the problem.

diff -cr postgresql-7.2.1/src/bin/pg_dump/pg_dumpall.sh postgresql/src/bin/pg_dump/pg_dumpall.sh
*** postgresql-7.2.1/src/bin/pg_dump/pg_dumpall.sh	Sun Feb 10 16:18:20 2002
--- postgresql/src/bin/pg_dump/pg_dumpall.sh	Tue Apr 23 14:22:56 2002
***************
*** 87,92 ****
--- 87,96 ----
echo "pg_dumpall (PostgreSQL) $VERSION"
exit 0
;;
+ 	    --quiet|-q)
+             quiet=t
+             break
+             ;;
--host|-h)
connectopts="$connectopts -h $2"
shift;;
***************
*** 144,149 ****
--- 148,154 ----
echo "  -g, --globals-only     Only dump global objects, no databases"
echo "  -h, --host=HOSTNAME    Server host name"
echo "  -p, --port=PORT        Server port number"
+     echo "  -q, --quiet            Don't print status messages to stderr"
echo "  -U, --username=NAME    Connect as specified database user"
echo "  -W, --password         Force password prompts (should happen automatically)"
echo "Any extra options will be passed to pg_dump.  The dump will be written"
***************
*** 169,175 ****
echo "DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');"
echo

! echo "connected to template1..." 1>&2
$PSQL -d template1 -At -c "\
SELECT
'CREATE USER \"' || usename || '\" WITH SYSID ' || usesysid
--- 174,180 ----
echo "DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');"
echo

! [ "$quiet" ] || echo "connected to template1..." 1>&2
$PSQL -d template1 -At -c "\
SELECT
'CREATE USER \"' || usename || '\" WITH SYSID ' || usesysid
***************
*** 235,241 ****
fi

echo "${BS}connect \"$DATABASE\" \"$DBOWNER\""
!     echo "dumping database \"$DATABASE\"..." 1>&2
$PGDUMP "$DATABASE" <&4
if [ "$?" -ne 0 ] ; then
echo "pg_dump failed on $DATABASE, exiting" 1>&2
--- 240,246 ----
fi

echo "${BS}connect \"$DATABASE\" \"$DBOWNER\""
! [ "$quiet" ] || echo "dumping database \"$DATABASE\"..." 1>&2
$PGDUMP "$DATABASE" <&4
if [ "$?" -ne 0 ] ; then
echo "pg_dump failed on $DATABASE, exiting" 1>&2

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Without showing the database being dumped, the entire output of
pg_dumpall seems pretty useless so you may as well pipe the whole output
to /dev/null. I don't think a quiet feature for pg_dumpall has enough
use for ordinary users. Sorry.

You seem to have missed the point completely - Neil wanted to suppress
the normal progress messages *on stderr* so that he'd only get an email
report when there was an abnormal event. That request seemed fine to
me, though I thought the patch itself might have some portability
issues. If it were recoded to follow the style of the existing boolean
options in pg_dumpall then I'd recommend accepting it.

regards, tom lane

Tom Lane writes:

You seem to have missed the point completely - Neil wanted to suppress
the normal progress messages *on stderr* so that he'd only get an email
report when there was an abnormal event. That request seemed fine to
me, though I thought the patch itself might have some portability
issues. If it were recoded to follow the style of the existing boolean
options in pg_dumpall then I'd recommend accepting it.

Two points:

1) The purpose of the progress messages is to inform the user of what
database he is connecting to. Previously, the user just got a prompt
"Password:" and had to guess which one. Unfortunately, it's hard for
pg_dumpall to predict whether a password prompt will appear.

This will become a nonissue soon because:

2) I'm currently rewriting pg_dumpall in C (as part of pg_dump actually),
so this patch will become obsolete.

(Also, I think we don't support external password files anymore, so the
password is now predictable and the progress messages can be removed, if
so.)

--
Peter Eisentraut peter_e@gmx.net