Specifies various behavioral properties of the TPSQLDump.
Set Options to include the desired properties for the dump. Options is a set drawn from the following values:
Dump only the data, not the object definitions (schema). This option is only meaningful for the plain-text format.
Include large objects in dump.
Output commands to clean (drop) database objects prior to (the commands for) creating them. Unless doIfExists is also specified, TPSQLRestore might generate some harmless error messages, if any objects were not present in the destination database. This option is only meaningful for the plain-text format.
Use conditional commands (i.e. add an IF EXISTS clause) when cleaning database objects. This option is not valid unless doClean is also specified.
Begin the output with a command to create the database itself and reconnect to the created database. (With a script of this form, it doesn't matter which database you connect to before running the script.) This option is only meaningful for the plain-text format.
Dump data as INSERT commands (rather than COPY). This will make restoration very slow; it is mainly useful for making dumps that can be loaded into non-PostgreSQL databases. Note that the restore may fail altogether if you have rearranged column order. The doColumnInserts option is safer, though even slower.
Dump data as INSERT commands with explicit column names (INSERT INTO table (column, ...) VALUES ...). This will make restoration very slow; it is mainly useful for making dumps that can be loaded into non-PostgreSQL databases.
A deprecated option that is now ignored.
Dump object identifiers (OIDs) for every table. Use this option if your application references the OID columns in some way (e.g., in a foreign key constraint). Otherwise, this option should not be used.
Do not output commands to set ownership of objects to match the original database. By default, TPSQLDump issues SET SESSION AUTHORIZATION statements to set ownership of created database objects.
These statements will fail when the script is run unless it is started by a superuser (or the same user that owns all of the objects in the script). To make a script that can be restored by any user, but will give that user ownership of all the objects, specify doNoOwner.
This option is only meaningful for the plain-text format.
Dump only the object definitions (schema), not data.
Specifies verbose mode. This will cause TPSQLDump to output detailed object comments and start/stop times to the dump file, and progress messages.
Prevent dumping of access privileges (grant/revoke commands).
This option disables the use of dollar quoting for function bodies, and forces them to be quoted using SQL standard string syntax.
This option is only relevant when creating a data-only dump. It instructs TPSQLDump to include commands to temporarily disable triggers on the target tables while the data is reloaded. Use this if you have referential integrity checks or other triggers on the tables that you do not want to invoke during data reload.
Presently, the commands emitted for doDisableTriggers must be done as superuser. So, you should also specify a SuperUserName property, or preferably be careful to start the resulting script as a superuser.
This option is only meaningful for the plain-text format.
Output SQL standard SET SESSION AUTHORIZATION commands instead of OWNER TO commands. This makes the dump more standards compatible, but depending on the history of the objects in the dump, may not restore properly.
Do not output commands to select tablespaces. With this option, all objects will be created in whichever tablespace is the default during restore. This option is only meaningful for the plain-text format. For the archive formats, you can specify the option when you use TPSQLRestore.
Force quoting of all identifiers. This may be useful when dumping a database for migration to a future version that may have introduced additional keywords.
Do not dump security labels.
Do not dump the contents of unlogged tables. This option has no effect on whether or not the table definitions (schema) are dumped; it only suppresses dumping the table data.
Use a serializable transaction for the dump, to ensure that the snapshot used is consistent with later database states; but do this by waiting for a point in the transaction stream at which no anomalies can be present, so that there isn't a risk of the dump failing or causing other transactions to roll back with a serialization_failure.
This option is not beneficial for a dump which is intended only for disaster recovery. It could be useful for a dump used to load a copy of the database for reporting or other read-only load sharing while the original database continues to be updated. Without it the dump may reflect a state which is not consistent with any serial execution of the transactions eventually committed. For example, if batch processing techniques are used, a batch may show as closed in the dump without all of the items which are in the batch appearing.
This option will make no difference if there are no read-write transactions active when dump is started. If read-write transactions are active, the start of the dump may be delayed for an indeterminate length of time. Once running, performance with or without the switch is the same.
This option is relevant only when dumping the contents of a table which has row security. By default, TPSQLDump will set row_security to off, to ensure that all data is dumped from the table. If the user does not have sufficient privileges to bypass row security, then an error is thrown. This parameter instructs TPSQLDump to set row_security to on instead, allowing the user to dump the parts of the contents of the table that they have access to.
Require that each schema (SchemaNames) and table (TableNames) match at least one schema/table in the database to be dumped. Note that if none of the schema/table qualifiers find matches, TPSQLDump will generate an error even without this option.
Exclude large objects in the dump. When both doNoBlobs and doBlobs are given, the behavior is to output large objects, when data is being dumped, see the doBlobs documentation.
By default, TPSQLDump will wait for all files to be written safely to disk. This option causes TPSQLDump to return without waiting, which is faster, but means that a subsequent operating system crash can leave the dump corrupt. Generally, this option is useful for testing but should not be used when dumping data from production installation.
Do not dump subscriptions.
Do not dump publications.