2000-07-21 13:40:08 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_backup.h
|
|
|
|
*
|
|
|
|
* Public interface to the pg_dump archiver routines.
|
|
|
|
*
|
|
|
|
* See the headers to pg_restore for more details.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2000, Philip Warner
|
2001-03-22 05:01:46 +01:00
|
|
|
* Rights are granted to use this software in any way so long
|
|
|
|
* as this notice is not removed.
|
2000-07-21 13:40:08 +02:00
|
|
|
*
|
|
|
|
* The author is not responsible for loss or damages that may
|
|
|
|
* result from it's use.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/bin/pg_dump/pg_backup.h
|
2000-08-01 17:51:45 +02:00
|
|
|
*
|
2000-07-21 13:40:08 +02:00
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
#ifndef PG_BACKUP_H
|
|
|
|
#define PG_BACKUP_H
|
2000-07-21 13:40:08 +02:00
|
|
|
|
2016-03-24 20:55:44 +01:00
|
|
|
#include "fe_utils/simple_list.h"
|
2000-07-21 13:40:08 +02:00
|
|
|
#include "libpq-fe.h"
|
|
|
|
|
2003-12-06 04:00:16 +01:00
|
|
|
|
2014-10-14 20:00:55 +02:00
|
|
|
typedef enum trivalue
|
2009-02-26 17:02:39 +01:00
|
|
|
{
|
|
|
|
TRI_DEFAULT,
|
|
|
|
TRI_NO,
|
|
|
|
TRI_YES
|
2014-10-14 20:00:55 +02:00
|
|
|
} trivalue;
|
2009-02-26 17:02:39 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
typedef enum _archiveFormat
|
|
|
|
{
|
2001-10-28 07:26:15 +01:00
|
|
|
archUnknown = 0,
|
|
|
|
archCustom = 1,
|
|
|
|
archTar = 3,
|
2011-01-23 22:10:15 +01:00
|
|
|
archNull = 4,
|
|
|
|
archDirectory = 5
|
2000-07-21 13:40:08 +02:00
|
|
|
} ArchiveFormat;
|
|
|
|
|
2007-01-25 04:30:43 +01:00
|
|
|
typedef enum _archiveMode
|
|
|
|
{
|
|
|
|
archModeAppend,
|
|
|
|
archModeWrite,
|
|
|
|
archModeRead
|
|
|
|
} ArchiveMode;
|
|
|
|
|
2009-02-02 21:07:37 +01:00
|
|
|
typedef enum _teSection
|
|
|
|
{
|
|
|
|
SECTION_NONE = 1, /* COMMENTs, ACLs, etc; can be anywhere */
|
|
|
|
SECTION_PRE_DATA, /* stuff to be processed before data */
|
|
|
|
SECTION_DATA, /* TABLE DATA, BLOBS, BLOB COMMENTS */
|
|
|
|
SECTION_POST_DATA /* stuff to be processed after data */
|
|
|
|
} teSection;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
typedef struct _restoreOptions
|
|
|
|
{
|
2010-05-15 23:41:16 +02:00
|
|
|
int createDB; /* Issue commands to create the database */
|
2005-10-15 04:49:52 +02:00
|
|
|
int noOwner; /* Don't try to match original object owner */
|
2009-06-11 16:49:15 +02:00
|
|
|
int noTablespace; /* Don't issue tablespace-related commands */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
int disable_triggers; /* disable triggers during data-only
|
|
|
|
* restore */
|
2017-06-21 20:39:04 +02:00
|
|
|
int use_setsessauth; /* Use SET SESSION AUTHORIZATION commands
|
|
|
|
* instead of OWNER TO */
|
2001-03-22 05:01:46 +01:00
|
|
|
char *superuser; /* Username to use as superuser */
|
2009-01-05 17:54:37 +01:00
|
|
|
char *use_role; /* Issue SET ROLE to this */
|
2000-07-21 13:40:08 +02:00
|
|
|
int dropSchema;
|
2014-10-14 20:00:55 +02:00
|
|
|
int disable_dollar_quoting;
|
|
|
|
int dump_inserts;
|
|
|
|
int column_inserts;
|
2014-03-03 19:02:18 +01:00
|
|
|
int if_exists;
|
Support --no-comments in pg_dump, pg_dumpall, pg_restore.
We have switches already to suppress other subsidiary object properties,
such as ACLs, security labels, ownership, and tablespaces, so just on
the grounds of symmetry we should allow suppressing comments as well.
Also, commit 0d4e6ed30 added a positive reason to have this feature,
i.e. to allow obtaining the old behavior of selective pg_restore should
anyone desire that.
Recent commits have removed the cases where pg_dump emitted comments on
built-in objects that the restoring user might not have privileges to
comment on, so the original primary motivation for this feature is gone,
but it still seems at least somewhat useful in its own right.
Robins Tharakan, reviewed by Fabrízio Mello
Discussion: https://postgr.es/m/CAEP4nAx22Z4ch74oJGzr5RyyjcyUSbpiFLyeYXX8pehfou92ug@mail.gmail.com
2018-01-25 21:27:24 +01:00
|
|
|
int no_comments; /* Skip comments */
|
2017-05-17 22:31:56 +02:00
|
|
|
int no_publications; /* Skip publication entries */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
int no_security_labels; /* Skip security label entries */
|
|
|
|
int no_subscriptions; /* Skip subscription entries */
|
2015-09-14 15:19:49 +02:00
|
|
|
int strict_names;
|
2014-10-14 20:00:55 +02:00
|
|
|
|
2012-02-07 22:20:29 +01:00
|
|
|
const char *filename;
|
Rewrite --section option to decouple it from --schema-only/--data-only.
The initial implementation of pg_dump's --section option supposed that the
existing --schema-only and --data-only options could be made equivalent to
--section settings. This is wrong, though, due to dubious but long since
set-in-stone decisions about where to dump SEQUENCE SET items, as seen in
bug report from Martin Pitt. (And I'm not totally convinced there weren't
other bugs, either.) Undo that coupling and instead drive --section
filtering off current-section state tracked as we scan through the TOC
list to call _tocEntryRequired().
To make sure those decisions don't shift around and hopefully save a few
cycles, run _tocEntryRequired() only once per TOC entry and save the result
in a new TOC field. This required minor rejiggering of ACL handling but
also allows a far cleaner implementation of inhibit_data_for_failed_table.
Also, to ensure that pg_dump and pg_restore have the same behavior with
respect to the --section switches, add _tocEntryRequired() filtering to
WriteToc() and WriteDataChunks(), rather than trying to implement section
filtering in an entirely orthogonal way in dumpDumpableObject(). This
required adjusting the handling of the special ENCODING and STDSTRINGS
items, but they were pretty weird before anyway.
Minor other code review for the patch, too.
2012-05-30 05:22:14 +02:00
|
|
|
int dataOnly;
|
2000-07-21 13:40:08 +02:00
|
|
|
int schemaOnly;
|
2012-06-10 21:20:04 +02:00
|
|
|
int dumpSections;
|
2000-07-21 13:40:08 +02:00
|
|
|
int verbose;
|
|
|
|
int aclsSkip;
|
2014-10-14 20:00:55 +02:00
|
|
|
const char *lockWaitTimeout;
|
|
|
|
int include_everything;
|
|
|
|
|
2000-07-21 13:40:08 +02:00
|
|
|
int tocSummary;
|
2001-03-22 05:01:46 +01:00
|
|
|
char *tocFile;
|
2000-07-21 13:40:08 +02:00
|
|
|
int format;
|
2001-03-22 05:01:46 +01:00
|
|
|
char *formatName;
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
int selTypes;
|
|
|
|
int selIndex;
|
|
|
|
int selFunction;
|
|
|
|
int selTrigger;
|
|
|
|
int selTable;
|
2013-08-28 08:43:34 +02:00
|
|
|
SimpleStringList indexNames;
|
|
|
|
SimpleStringList functionNames;
|
|
|
|
SimpleStringList schemaNames;
|
2016-09-20 18:00:00 +02:00
|
|
|
SimpleStringList schemaExcludeNames;
|
2013-08-28 08:43:34 +02:00
|
|
|
SimpleStringList triggerNames;
|
2013-01-17 11:24:47 +01:00
|
|
|
SimpleStringList tableNames;
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
int useDB;
|
2016-08-08 16:07:46 +02:00
|
|
|
char *dbname; /* subject to expand_dbname */
|
2001-03-22 05:01:46 +01:00
|
|
|
char *pgport;
|
|
|
|
char *pghost;
|
2001-05-17 23:12:49 +02:00
|
|
|
char *username;
|
2006-08-01 20:21:44 +02:00
|
|
|
int noDataForFailedTables;
|
2014-10-14 20:00:55 +02:00
|
|
|
trivalue promptPassword;
|
2004-08-20 06:20:23 +02:00
|
|
|
int exit_on_error;
|
2000-08-01 17:51:45 +02:00
|
|
|
int compression;
|
2005-10-15 04:49:52 +02:00
|
|
|
int suppressDumpWarnings; /* Suppress output of WARNING entries
|
|
|
|
* to stderr */
|
2006-10-04 02:30:14 +02:00
|
|
|
bool single_txn;
|
2006-02-12 05:04:32 +01:00
|
|
|
|
2006-10-15 01:07:22 +02:00
|
|
|
bool *idWanted; /* array showing which dump IDs to emit */
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
int enable_row_security;
|
2016-08-23 18:00:00 +02:00
|
|
|
int sequence_data; /* dump sequence data even in schema-only mode */
|
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the information which can be associated
with large objects. Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.
As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well. With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.
In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want. In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.
Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/20170221162655.GE9812@tamriel.snowman.net
2017-03-06 23:03:57 +01:00
|
|
|
int binary_upgrade;
|
2000-07-21 13:40:08 +02:00
|
|
|
} RestoreOptions;
|
|
|
|
|
2014-10-14 20:00:55 +02:00
|
|
|
typedef struct _dumpOptions
|
|
|
|
{
|
2016-08-08 16:07:46 +02:00
|
|
|
const char *dbname; /* subject to expand_dbname */
|
2014-10-14 20:00:55 +02:00
|
|
|
const char *pghost;
|
|
|
|
const char *pgport;
|
|
|
|
const char *username;
|
|
|
|
|
|
|
|
int binary_upgrade;
|
|
|
|
|
|
|
|
/* various user-settable parameters */
|
|
|
|
bool schemaOnly;
|
|
|
|
bool dataOnly;
|
|
|
|
int dumpSections; /* bitmask of chosen sections */
|
|
|
|
bool aclsSkip;
|
|
|
|
const char *lockWaitTimeout;
|
2019-03-07 13:26:14 +01:00
|
|
|
int dump_inserts; /* 0 = COPY, otherwise rows per INSERT */
|
2014-10-14 20:00:55 +02:00
|
|
|
|
|
|
|
/* flags for various command-line long options */
|
|
|
|
int disable_dollar_quoting;
|
|
|
|
int column_inserts;
|
|
|
|
int if_exists;
|
Support --no-comments in pg_dump, pg_dumpall, pg_restore.
We have switches already to suppress other subsidiary object properties,
such as ACLs, security labels, ownership, and tablespaces, so just on
the grounds of symmetry we should allow suppressing comments as well.
Also, commit 0d4e6ed30 added a positive reason to have this feature,
i.e. to allow obtaining the old behavior of selective pg_restore should
anyone desire that.
Recent commits have removed the cases where pg_dump emitted comments on
built-in objects that the restoring user might not have privileges to
comment on, so the original primary motivation for this feature is gone,
but it still seems at least somewhat useful in its own right.
Robins Tharakan, reviewed by Fabrízio Mello
Discussion: https://postgr.es/m/CAEP4nAx22Z4ch74oJGzr5RyyjcyUSbpiFLyeYXX8pehfou92ug@mail.gmail.com
2018-01-25 21:27:24 +01:00
|
|
|
int no_comments;
|
2014-10-14 20:00:55 +02:00
|
|
|
int no_security_labels;
|
2017-05-12 15:15:40 +02:00
|
|
|
int no_publications;
|
2017-05-09 16:58:06 +02:00
|
|
|
int no_subscriptions;
|
2014-10-14 20:00:55 +02:00
|
|
|
int no_synchronized_snapshots;
|
|
|
|
int no_unlogged_table_data;
|
|
|
|
int serializable_deferrable;
|
|
|
|
int quote_all_identifiers;
|
|
|
|
int disable_triggers;
|
|
|
|
int outputNoTablespaces;
|
|
|
|
int use_setsessauth;
|
|
|
|
int enable_row_security;
|
2017-08-15 04:54:41 +02:00
|
|
|
int load_via_partition_root;
|
2014-10-14 20:00:55 +02:00
|
|
|
|
|
|
|
/* default, if no "inclusion" switches appear, is to dump everything */
|
|
|
|
bool include_everything;
|
|
|
|
|
|
|
|
int outputClean;
|
|
|
|
int outputCreateDB;
|
|
|
|
bool outputBlobs;
|
2016-11-29 17:09:35 +01:00
|
|
|
bool dontOutputBlobs;
|
2014-10-14 20:00:55 +02:00
|
|
|
int outputNoOwner;
|
|
|
|
char *outputSuperuser;
|
2016-08-23 18:00:00 +02:00
|
|
|
|
|
|
|
int sequence_data; /* dump sequence data even in schema-only mode */
|
2018-07-13 03:57:03 +02:00
|
|
|
int do_nothing;
|
2014-10-14 20:00:55 +02:00
|
|
|
} DumpOptions;
|
|
|
|
|
2016-01-13 23:48:33 +01:00
|
|
|
/*
|
|
|
|
* We may want to have some more user-readable data, but in the mean
|
|
|
|
* time this gives us some abstraction and type checking.
|
|
|
|
*/
|
|
|
|
typedef struct Archive
|
|
|
|
{
|
|
|
|
DumpOptions *dopt; /* options, if dumping */
|
|
|
|
RestoreOptions *ropt; /* options, if restoring */
|
|
|
|
|
|
|
|
int verbose;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
char *remoteVersionStr; /* server's version string */
|
2016-01-13 23:48:33 +01:00
|
|
|
int remoteVersion; /* same in numeric form */
|
2016-05-26 22:14:23 +02:00
|
|
|
bool isStandby; /* is server a standby node */
|
2016-01-13 23:48:33 +01:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
int minRemoteVersion; /* allowable range */
|
2016-01-13 23:48:33 +01:00
|
|
|
int maxRemoteVersion;
|
|
|
|
|
|
|
|
int numWorkers; /* number of parallel processes */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
char *sync_snapshot_id; /* sync snapshot id for parallel operation */
|
2016-01-13 23:48:33 +01:00
|
|
|
|
|
|
|
/* info needed for string escaping */
|
|
|
|
int encoding; /* libpq code for client_encoding */
|
|
|
|
bool std_strings; /* standard_conforming_strings */
|
Avoid using unsafe search_path settings during dump and restore.
Historically, pg_dump has "set search_path = foo, pg_catalog" when
dumping an object in schema "foo", and has also caused that setting
to be used while restoring the object. This is problematic because
functions and operators in schema "foo" could capture references meant
to refer to pg_catalog entries, both in the queries issued by pg_dump
and those issued during the subsequent restore run. That could
result in dump/restore misbehavior, or in privilege escalation if a
nefarious user installs trojan-horse functions or operators.
This patch changes pg_dump so that it does not change the search_path
dynamically. The emitted restore script sets the search_path to what
was used at dump time, and then leaves it alone thereafter. Created
objects are placed in the correct schema, regardless of the active
search_path, by dint of schema-qualifying their names in the CREATE
commands, as well as in subsequent ALTER and ALTER-like commands.
Since this change requires a change in the behavior of pg_restore
when processing an archive file made according to this new convention,
bump the archive file version number; old versions of pg_restore will
therefore refuse to process files made with new versions of pg_dump.
Security: CVE-2018-1058
2018-02-26 16:18:21 +01:00
|
|
|
|
|
|
|
/* other important stuff */
|
|
|
|
char *searchpath; /* search_path to set during restore */
|
2016-01-13 23:48:33 +01:00
|
|
|
char *use_role; /* Issue SET ROLE to this */
|
|
|
|
|
|
|
|
/* error handling */
|
|
|
|
bool exit_on_error; /* whether to exit on SQL errors... */
|
|
|
|
int n_errors; /* number of errors (if no die) */
|
|
|
|
|
|
|
|
/* The rest is private */
|
|
|
|
} Archive;
|
|
|
|
|
2014-10-14 20:00:55 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* pg_dump uses two different mechanisms for identifying database objects:
|
|
|
|
*
|
|
|
|
* CatalogId represents an object by the tableoid and oid of its defining
|
|
|
|
* entry in the system catalogs. We need this to interpret pg_depend entries,
|
|
|
|
* for instance.
|
|
|
|
*
|
|
|
|
* DumpId is a simple sequential integer counter assigned as dumpable objects
|
|
|
|
* are identified during a pg_dump run. We use DumpId internally in preference
|
|
|
|
* to CatalogId for two reasons: it's more compact, and we can assign DumpIds
|
|
|
|
* to "objects" that don't have a separate CatalogId. For example, it is
|
|
|
|
* convenient to consider a table, its data, and its ACL as three separate
|
|
|
|
* dumpable "objects" with distinct DumpIds --- this lets us reason about the
|
|
|
|
* order in which to dump these things.
|
|
|
|
*/
|
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
Oid tableoid;
|
|
|
|
Oid oid;
|
|
|
|
} CatalogId;
|
|
|
|
|
|
|
|
typedef int DumpId;
|
|
|
|
|
2016-01-13 23:48:33 +01:00
|
|
|
typedef int (*DataDumperPtr) (Archive *AH, void *userArg);
|
2014-10-14 20:00:55 +02:00
|
|
|
|
2016-08-30 18:00:00 +02:00
|
|
|
typedef void (*SetupWorkerPtrType) (Archive *AH);
|
2013-03-24 16:27:20 +01:00
|
|
|
|
2000-07-21 13:40:08 +02:00
|
|
|
/*
|
|
|
|
* Main archiver interface.
|
|
|
|
*/
|
|
|
|
|
2012-02-16 19:00:24 +01:00
|
|
|
extern void ConnectDatabase(Archive *AH,
|
2019-05-22 19:04:48 +02:00
|
|
|
const char *dbname,
|
|
|
|
const char *pghost,
|
|
|
|
const char *pgport,
|
|
|
|
const char *username,
|
|
|
|
trivalue prompt_password);
|
2012-02-16 17:49:20 +01:00
|
|
|
extern void DisconnectDatabase(Archive *AHX);
|
2012-02-16 19:00:24 +01:00
|
|
|
extern PGconn *GetConnection(Archive *AHX);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
/* Called to write *data* to the archive */
|
2014-05-06 02:27:16 +02:00
|
|
|
extern void WriteData(Archive *AH, const void *data, size_t dLen);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
2001-04-01 07:42:51 +02:00
|
|
|
extern int StartBlob(Archive *AH, Oid oid);
|
|
|
|
extern int EndBlob(Archive *AH, Oid oid);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
2016-01-13 23:48:33 +01:00
|
|
|
extern void CloseArchive(Archive *AH);
|
|
|
|
|
|
|
|
extern void SetArchiveOptions(Archive *AH, DumpOptions *dopt, RestoreOptions *ropt);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
2016-01-13 23:48:33 +01:00
|
|
|
extern void ProcessArchiveRestoreOptions(Archive *AH);
|
Rewrite --section option to decouple it from --schema-only/--data-only.
The initial implementation of pg_dump's --section option supposed that the
existing --schema-only and --data-only options could be made equivalent to
--section settings. This is wrong, though, due to dubious but long since
set-in-stone decisions about where to dump SEQUENCE SET items, as seen in
bug report from Martin Pitt. (And I'm not totally convinced there weren't
other bugs, either.) Undo that coupling and instead drive --section
filtering off current-section state tracked as we scan through the TOC
list to call _tocEntryRequired().
To make sure those decisions don't shift around and hopefully save a few
cycles, run _tocEntryRequired() only once per TOC entry and save the result
in a new TOC field. This required minor rejiggering of ACL handling but
also allows a far cleaner implementation of inhibit_data_for_failed_table.
Also, to ensure that pg_dump and pg_restore have the same behavior with
respect to the --section switches, add _tocEntryRequired() filtering to
WriteToc() and WriteDataChunks(), rather than trying to implement section
filtering in an entirely orthogonal way in dumpDumpableObject(). This
required adjusting the handling of the special ENCODING and STDSTRINGS
items, but they were pretty weird before anyway.
Minor other code review for the patch, too.
2012-05-30 05:22:14 +02:00
|
|
|
|
|
|
|
extern void RestoreArchive(Archive *AH);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
/* Open an existing archive */
|
2001-03-22 05:01:46 +01:00
|
|
|
extern Archive *OpenArchive(const char *FileSpec, const ArchiveFormat fmt);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
/* Create a new archive */
|
2001-03-22 05:01:46 +01:00
|
|
|
extern Archive *CreateArchive(const char *FileSpec, const ArchiveFormat fmt,
|
2019-05-22 19:04:48 +02:00
|
|
|
const int compression, bool dosync, ArchiveMode mode,
|
|
|
|
SetupWorkerPtrType setupDumpWorker);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
/* The --list option */
|
2016-01-13 23:48:33 +01:00
|
|
|
extern void PrintTOCSummary(Archive *AH);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
extern RestoreOptions *NewRestoreOptions(void);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
2014-10-14 20:00:55 +02:00
|
|
|
extern DumpOptions *NewDumpOptions(void);
|
2015-01-11 19:28:26 +01:00
|
|
|
extern void InitDumpOptions(DumpOptions *opts);
|
2014-10-14 20:00:55 +02:00
|
|
|
extern DumpOptions *dumpOptionsFromRestoreOptions(RestoreOptions *ropt);
|
|
|
|
|
2006-10-15 01:07:22 +02:00
|
|
|
/* Rearrange and filter TOC entries */
|
2016-01-13 23:48:33 +01:00
|
|
|
extern void SortTocFromFile(Archive *AHX);
|
2000-07-21 13:40:08 +02:00
|
|
|
|
|
|
|
/* Convenience functions used only when writing DATA */
|
2014-05-06 18:12:18 +02:00
|
|
|
extern void archputs(const char *s, Archive *AH);
|
2015-03-26 19:03:19 +01:00
|
|
|
extern int archprintf(Archive *AH, const char *fmt,...) pg_attribute_printf(2, 3);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2006-05-28 23:13:54 +02:00
|
|
|
#define appendStringLiteralAH(buf,str,AH) \
|
|
|
|
appendStringLiteral(buf, str, (AH)->encoding, (AH)->std_strings)
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* PG_BACKUP_H */
|