Re: pg_dump no longer honors --no-reconnect - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_dump no longer honors --no-reconnect
Date
Msg-id 200309291535.h8TFZgY21612@candle.pha.pa.us
Whole thread Raw
In response to Re: pg_dump no longer honors --no-reconnect  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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.)

Oh, OK, thanks.  My initial mistake was reading --no-reconnect as
--reconnect; not sure how I did that.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: initdb failure
Next
From: Tom Lane
Date:
Subject: Re: 2-phase commit