pg_dump no longer honors --no-reconnect
From CVS logs I see:
pg_dump/pg_restore now always use SET SESSION AUTHORIZATION, not
\connect, to control object ownership. The
use-set-session-authorization and no-reconnect switches are obsolete
(still accepted on the command line, but they don't do anything). This
is a precursor to fixing handling of CREATE SCHEMA, which will be a
separate commit.
This was to fix a problem with restoring schemas. However, the commit
says that --use-set-session-authorization and --no-reconnect are no
longer honored. Seems we can silently ignore a
--use-set-session-authorization flag because that is now the default,
but I don't see how we can ignore a --no-reconnect flag --- we should
throw an error.
The pg_dump manual says:
-R
--no-reconnect
This option is obsolete but still accepted for backwards compatibility.
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.
--
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, Pennsylvania 19073
Bruce Momjian writes:
Seems we can silently ignore a --use-set-session-authorization flag
because that is now the default, but I don't see how we can ignore a
--no-reconnect flag --- we should throw an error.
Why? The new bevavior of pg_dump is to never reconnect -- exactly the
point of this change.
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.
It had been dicussed on and off for quite some time. This limitation
should only apply if you create dumps that contain objects owned by more
than one user. (Does it? I didn't check.)
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
Bruce Momjian writes:
Seems we can silently ignore a --use-set-session-authorization flag
because that is now the default, but I don't see how we can ignore a
--no-reconnect flag --- we should throw an error.Why? The new bevavior of pg_dump is to never reconnect -- exactly the
point of this change.
Oh, sorry, I see now. I got --no-reconnect confused with --reconnect,
which would say we want to reconnect. I now see the option handling is
fine because we do both by default.
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.It had been dicussed on and off for quite some time. This limitation
should only apply if you create dumps that contain objects owned by more
than one user. (Does it? I didn't check.)
Yes, but didn't the old code prompt you for passwords, or silently work
if you had things set to 'trust', while our new code requires
super-user?
--
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, Pennsylvania 19073
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.)
regards, tom lane
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, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
Peter Eisentraut wrote:
It had been dicussed on and off for quite some time. This limitation
should only apply if you create dumps that contain objects owned by more
than one user. (Does it? I didn't check.)
Yes, but didn't the old code prompt you for passwords, or silently work
if you had things set to 'trust', while our new code requires
super-user?
If you have things set to "trust", you can be superuser, eh?
A password approach might be workable using ~/.pgpass, but only in a
scenario where (a) a non-superuser has everyone else's passwords in his
~/.pgpass, and (b) there are no superuser-owned objects in the dump.
Neither of those assumptions hold up to scrutiny.
In practice I think use-set-session-auth is vastly the superior
technique, especially considering you can use --no-owner if you
really don't want any SET SESSION AUTH commands in there.
regards, tom lane
Tom Lane wrote:
Yes, but didn't the old code prompt you for passwords, or silently work
if you had things set to 'trust', while our new code requires
super-user?If you have things set to "trust", you can be superuser, eh?
A password approach might be workable using ~/.pgpass, but only in a
scenario where (a) a non-superuser has everyone else's passwords in his
~/.pgpass, and (b) there are no superuser-owned objects in the dump.
Neither of those assumptions hold up to scrutiny.In practice I think use-set-session-auth is vastly the superior
technique, especially considering you can use --no-owner if you
really don't want any SET SESSION AUTH commands in there.
Agreed. Sorry for the confusion I caused.
--
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, Pennsylvania 19073Peter Eisentraut <peter_e@gmx.net> writes:
It had been dicussed on and off for quite some time. This limitation
should only apply if you create dumps that contain objects owned by more
than one user. (Does it? I didn't check.)
Yes, because "SET SESSION AUTHORIZATION yourself" is allowed even if
you're not superuser. So for dumps containing only your own objects,
there's really no issue.
regards, tom lane