$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.64 2003/09/11 21:42:20 momjian Exp $

Do not output commands to set the

object ownership to match the original database. Typically,

<application>pg_dump</application> issues

(<application>psql</application>-specific) <command>\connect</command>

statements to set ownership of schema elements. See also

under <option>-R</option> and <option>-X

use-set-session-authorization</option>. Note that

<option>-O</option> does not prevent all reconnections to the

database, only the ones that are exclusively used for

ownership adjustments.

Prohibit <application>pg_dump</application>

from outputting a script that would require reconnections to

the database while being restored. An average restoration

script usually has to reconnect several times as different

users to set the original ownerships of the objects. This

option is a rather blunt instrument because it makes

<application>pg_dump</application> lose this ownership information,

<emphasis>unless</emphasis> you use the <option>-X

use-set-session-authorization</option> option.

</para>

<para>

One possible reason why reconnections during restore might not

be desired is if the access to the database requires manual

interaction (e.g., passwords).

</para>

<para>

This option is only meaningful for the plain-text format. For

the other formats, you may specify the option when you

call <command>pg_restore</command>.

(Usually, it's better to specify

<option>--use-set-session-authorization</>, and then start the

Normally, if a (plain-text mode) script generated by

<application>pg_dump</application> must alter the current database

user (e.g., to set correct object ownerships), it uses the

<application>psql</application> <command>\connect</command> command.

This command actually opens a new connection, which might

require manual interaction (e.g., passwords). If you use the

<option>-X use-set-session-authorization</option> option, then

<application>pg_dump</application> will instead output <xref

linkend="sql-set-session-authorization" endterm="sql-set-session-authorization-title"> commands. This has

the same effect, but it requires that the user restoring the

database from the generated script be a database superuser.

This option effectively overrides the <option>-R</option>

option.

</para>

<para>

Since <xref linkend="sql-set-session-authorization" endterm="sql-set-session-authorization-title"> is a

standard SQL command, whereas <command>\connect</command> only

works in <application>psql</application>, this option also enhances

the theoretical portability of the output script.

</para>

<para>

This option is only meaningful for the plain-text format. For

the other formats, you may specify the option when you

call <command>pg_restore</command>.

a superuser name with <option>-S</>, or preferably specify

<option>--use-set-session-authorization</> and then be careful to

start the resulting script as a superuser. If you give neither

option, the entire script must be run as superuser.

<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.42 2003/09/11 21:42:20 momjian Exp $ -->

Prevent any attempt to restore original object

ownership. Objects will be owned by the user name used to

attach to the database. See also under <option>-R</option> and

<option>-X use-set-session-authorization</option>.

While restoring an archive, <application>pg_restore</application>

typically has to reconnect to the database several times with

different user names to set the correct ownership of the

created objects. If this is undesirable (e.g., because manual

interaction (passwords) would be necessary for each

reconnection), this option prevents

<application>pg_restore</application> from issuing any reconnection

requests. (A connection request while in plain text mode, not

connected to a database, is made by putting out a <xref

linkend="app-psql"> <command>\connect</command> command.)

However, this option is a rather blunt instrument because it

makes <application>pg_restore</application> lose all object ownership

information, <emphasis>unless</emphasis> you use the

<option>-X use-set-session-authorization</option> option.

Normally, if restoring an archive requires altering the

current database user (e.g., to set correct object

ownerships), a new connection to the database must be opened,

which might require manual interaction (e.g., passwords). If

you use the <option>-X use-set-session-authorization</option> option,

then <application>pg_restore</application> will instead use the <xref

linkend="sql-set-session-authorization" endterm="sql-set-session-authorization-title"> command. This has

the same effect, but it requires that the user restoring the

archive is a database superuser. This option effectively

overrides the <option>-R</option> option.

preferably specify <option>--use-set-session-authorization</> and

run <application>pg_restore</application> as a

int noOwner; /* Don't reconnect to database to match

int noReconnect; /* Don't reconnect to database under any

int use_setsessauth;/* use SET SESSSION AUTHORIZATION instead