Re: [HACKERS] An item for the TODO list: pg_dump and multiple table owners

>
> pg_dump doesn't cope very gracefully at all with databases containing
> multiple tables not all owned by the same person. It knows enough
> to issue \connect commands in the reload script that cause the
> new tables to be owned by the same people as before. But the reload
> script fails with permission errors later on during the data copying
> phase, if the tables are not made world-writable.
>
> This is certain to happen if the -z switch is not used to dump the
> tables' grant/revoke status. I suspect that pg_dump ought not try
> to save/restore table ownership unless it is also saving/restoring
> access rights; that is, if -z is not given the \connect commands
> shouldn't appear either. Then, without -z the reload script will
> generate a new database wholly owned by the script invoker.
>
> When using -z, the failure of the copy-in command could be fixed by
> issuing more \connect commands so that the data transfer is done while
> logged in as the table owner.
>
> This is particularly nasty because the reload script fails even if
> run as the Postgres superuser. I think this is because the script
> reconnects as the various table owners and thereby loses superuser
> access rights.

This is a very good point. I will look into it.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)