* Tom Lane <tgl@sss.pgh.pa.us> [010101 13:16]:
> Larry Rosenman <ler@lerctr.org> writes:
> > I noticed today that pg_dumpall from current CVS does *NOT*
> > dump a password assiged to the postgres user.
>
> > I consider this BAD, since if one has to restore from
> > a pg_dumpall, one may forget to reset the password.
>
> I'm unconvinced. The pg_dumpall script is clearly intended to allow
> restoration into a new database installation with a different superuser;
> you will note that the script is careful not to assume that the old and
> new superuser names are the same (an assumption your proposed patch
> does make).
>
> In any case the new installation certainly already *has* a superuser.
> I'm not sure it's the job of the restore script to change his password
> for him.
>
> This does point up that there is some state that is not saved/restored
> by pg_dumpall --- the pg_hba.conf file and other config files that
> live in $PGDATA come to mind. Perhaps there should be a separate
> utility that saves/restores these. (pg_dump can't do it because there's
> no way to retrieve these files through a database connection.)
How would you suggest doing this? A shell script that makes a SHAR or
somesuch? Or what? Should it save the SuperUser password?
I agree that this is a shortcoming.
As to the SuperUser password thing, how do we remind the user that
they had one set? Can we at least put out a comment in the pg_dumpall
output that mentions it?
>
> regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749