| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump no longer honors --no-reconnect |
| Date: | 2003-09-29 15:30:06 |
| Message-ID: | 24641.1064849406@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> but I don't see how we can ignore a --no-reconnect flag --- we should
> throw an error.
We can ignore it because we don't reconnect. I only took out the flag
because I noticed it was no longer tested anywhere after I removed the
\connect code paths. I'm not sure if the old docs mentioned that
--no-reconnect was irrelevant when using set-session-authorization,
but that's how the code behaved.
> Also, the 7.3 manual mentions that only the super-user can restore using
> --use-set-session-authorization. This is now the only way to create
> dumps. Seems this is a new limitation to pg_dump that we didn't
> discuss.
No, because a non-superuser can still restore with --no-owner; which is
actually a step forward over what he could have done with a \connect script.
(Unless you think that the scenario of a non-superuser who knows
everyone's password is something pg_dump needs to cater to.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-09-29 15:35:42 | Re: pg_dump no longer honors --no-reconnect |
| Previous Message | Tom Lane | 2003-09-29 15:21:35 | Re: Alter Table Column Datatype |