postgresql/doc/src/sgml/reference.sgml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

299 lines
6.1 KiB
Plaintext
Raw Permalink Normal View History

2010-09-20 22:08:53 +02:00
<!-- doc/src/sgml/reference.sgml -->
<part id="reference">
<title>Reference</title>
<partintro>
<para>
The entries in this Reference are meant to provide in reasonable
length an authoritative, complete, and formal summary about their
respective subjects. More information about the use of
<productname>PostgreSQL</productname>, in narrative, tutorial, or
example form, can be found in other parts of this book. See the
cross-references listed on each reference page.
</para>
<para>
The reference entries are also available as traditional
<quote>man</quote> pages.
</para>
</partintro>
<reference id="sql-commands">
<title>SQL Commands</title>
1998-05-13 07:34:39 +02:00
<partintro>
<para>
This part contains reference information for the
<acronym>SQL</acronym> commands supported by
<productname>PostgreSQL</productname>. By <quote>SQL</quote> the
language in general is meant; information about the standards
conformance and compatibility of each command can be found on the
respective reference page.
</para>
</partintro>
&abort;
2003-06-27 16:45:32 +02:00
&alterAggregate;
&alterCollation;
2003-06-27 16:45:32 +02:00
&alterConversion;
&alterDatabase;
&alterDefaultPrivileges;
2002-12-06 06:00:34 +01:00
&alterDomain;
&alterEventTrigger;
&alterExtension;
&alterForeignDataWrapper;
&alterForeignTable;
2003-06-27 16:45:32 +02:00
&alterFunction;
&alterGroup;
&alterIndex;
2003-06-27 16:45:32 +02:00
&alterLanguage;
&alterLargeObject;
&alterMaterializedView;
&alterOperator;
2003-06-27 16:45:32 +02:00
&alterOperatorClass;
&alterOperatorFamily;
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
&alterPolicy;
&alterProcedure;
&alterPublication;
&alterRole;
&alterRoutine;
&alterRule;
2003-06-27 16:45:32 +02:00
&alterSchema;
&alterSequence;
&alterServer;
Implement multivariate n-distinct coefficients Add support for explicitly declared statistic objects (CREATE STATISTICS), allowing collection of statistics on more complex combinations that individual table columns. Companion commands DROP STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are added too. All this DDL has been designed so that more statistic types can be added later on, such as multivariate most-common-values and multivariate histograms between columns of a single table, leaving room for permitting columns on multiple tables, too, as well as expressions. This commit only adds support for collection of n-distinct coefficient on user-specified sets of columns in a single table. This is useful to estimate number of distinct groups in GROUP BY and DISTINCT clauses; estimation errors there can cause over-allocation of memory in hashed aggregates, for instance, so it's a worthwhile problem to solve. A new special pseudo-type pg_ndistinct is used. (num-distinct estimation was deemed sufficiently useful by itself that this is worthwhile even if no further statistic types are added immediately; so much so that another version of essentially the same functionality was submitted by Kyotaro Horiguchi: https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp though this commit does not use that code.) Author: Tomas Vondra. Some code rework by Álvaro. Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes, Ideriha Takeshi Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
&alterStatistics;
&alterSubscription;
&alterSystem;
&alterTable;
&alterTableSpace;
&alterTSConfig;
&alterTSDictionary;
&alterTSParser;
&alterTSTemplate;
&alterTrigger;
&alterType;
&alterUser;
&alterUserMapping;
&alterView;
&analyze;
&begin;
&call;
&checkpoint;
&close;
&cluster;
&commentOn;
&commit;
&commitPrepared;
&copyTable;
&createAccessMethod;
&createAggregate;
&createCast;
&createCollation;
&createConversion;
&createDatabase;
&createDomain;
&createEventTrigger;
&createExtension;
&createForeignDataWrapper;
&createForeignTable;
&createFunction;
&createGroup;
&createIndex;
&createLanguage;
&createMaterializedView;
&createOperator;
&createOperatorClass;
&createOperatorFamily;
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
&createPolicy;
&createProcedure;
&createPublication;
&createRole;
&createRule;
&createSchema;
&createSequence;
&createServer;
Implement multivariate n-distinct coefficients Add support for explicitly declared statistic objects (CREATE STATISTICS), allowing collection of statistics on more complex combinations that individual table columns. Companion commands DROP STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are added too. All this DDL has been designed so that more statistic types can be added later on, such as multivariate most-common-values and multivariate histograms between columns of a single table, leaving room for permitting columns on multiple tables, too, as well as expressions. This commit only adds support for collection of n-distinct coefficient on user-specified sets of columns in a single table. This is useful to estimate number of distinct groups in GROUP BY and DISTINCT clauses; estimation errors there can cause over-allocation of memory in hashed aggregates, for instance, so it's a worthwhile problem to solve. A new special pseudo-type pg_ndistinct is used. (num-distinct estimation was deemed sufficiently useful by itself that this is worthwhile even if no further statistic types are added immediately; so much so that another version of essentially the same functionality was submitted by Kyotaro Horiguchi: https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp though this commit does not use that code.) Author: Tomas Vondra. Some code rework by Álvaro. Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes, Ideriha Takeshi Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
&createStatistics;
&createSubscription;
&createTable;
&createTableAs;
&createTableSpace;
&createTSConfig;
&createTSDictionary;
&createTSParser;
&createTSTemplate;
&createTransform;
&createTrigger;
&createType;
&createUser;
&createUserMapping;
&createView;
&deallocate;
&declare;
&delete;
&discard;
&do;
&dropAccessMethod;
&dropAggregate;
&dropCast;
&dropCollation;
&dropConversion;
&dropDatabase;
&dropDomain;
&dropEventTrigger;
&dropExtension;
&dropForeignDataWrapper;
&dropForeignTable;
&dropFunction;
&dropGroup;
&dropIndex;
&dropLanguage;
&dropMaterializedView;
&dropOperator;
&dropOperatorClass;
&dropOperatorFamily;
&dropOwned;
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
&dropPolicy;
&dropProcedure;
&dropPublication;
&dropRole;
&dropRoutine;
&dropRule;
&dropSchema;
&dropSequence;
&dropServer;
Implement multivariate n-distinct coefficients Add support for explicitly declared statistic objects (CREATE STATISTICS), allowing collection of statistics on more complex combinations that individual table columns. Companion commands DROP STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are added too. All this DDL has been designed so that more statistic types can be added later on, such as multivariate most-common-values and multivariate histograms between columns of a single table, leaving room for permitting columns on multiple tables, too, as well as expressions. This commit only adds support for collection of n-distinct coefficient on user-specified sets of columns in a single table. This is useful to estimate number of distinct groups in GROUP BY and DISTINCT clauses; estimation errors there can cause over-allocation of memory in hashed aggregates, for instance, so it's a worthwhile problem to solve. A new special pseudo-type pg_ndistinct is used. (num-distinct estimation was deemed sufficiently useful by itself that this is worthwhile even if no further statistic types are added immediately; so much so that another version of essentially the same functionality was submitted by Kyotaro Horiguchi: https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp though this commit does not use that code.) Author: Tomas Vondra. Some code rework by Álvaro. Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes, Ideriha Takeshi Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
&dropStatistics;
&dropSubscription;
&dropTable;
&dropTableSpace;
&dropTSConfig;
&dropTSDictionary;
&dropTSParser;
&dropTSTemplate;
&dropTransform;
&dropTrigger;
&dropType;
&dropUser;
&dropUserMapping;
&dropView;
&end;
&execute;
&explain;
&fetch;
&grant;
&importForeignSchema;
&insert;
&listen;
&load;
&lock;
Add support for MERGE SQL command MERGE performs actions that modify rows in the target table using a source table or query. MERGE provides a single SQL statement that can conditionally INSERT/UPDATE/DELETE rows -- a task that would otherwise require multiple PL statements. For example, MERGE INTO target AS t USING source AS s ON t.tid = s.sid WHEN MATCHED AND t.balance > s.delta THEN UPDATE SET balance = t.balance - s.delta WHEN MATCHED THEN DELETE WHEN NOT MATCHED AND s.delta > 0 THEN INSERT VALUES (s.sid, s.delta) WHEN NOT MATCHED THEN DO NOTHING; MERGE works with regular tables, partitioned tables and inheritance hierarchies, including column and row security enforcement, as well as support for row and statement triggers and transition tables therein. MERGE is optimized for OLTP and is parameterizable, though also useful for large scale ETL/ELT. MERGE is not intended to be used in preference to existing single SQL commands for INSERT, UPDATE or DELETE since there is some overhead. MERGE can be used from PL/pgSQL. MERGE does not support targetting updatable views or foreign tables, and RETURNING clauses are not allowed either. These limitations are likely fixable with sufficient effort. Rewrite rules are also not supported, but it's not clear that we'd want to support them. Author: Pavan Deolasee <pavan.deolasee@gmail.com> Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Author: Amit Langote <amitlangote09@gmail.com> Author: Simon Riggs <simon.riggs@enterprisedb.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Andres Freund <andres@anarazel.de> (earlier versions) Reviewed-by: Peter Geoghegan <pg@bowt.ie> (earlier versions) Reviewed-by: Robert Haas <robertmhaas@gmail.com> (earlier versions) Reviewed-by: Japin Li <japinli@hotmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CANP8+jKitBSrB7oTgT9CY2i1ObfOt36z0XMraQc+Xrz8QB0nXA@mail.gmail.com Discussion: https://postgr.es/m/CAH2-WzkJdBuxj9PO=2QaO9-3h3xGbQPZ34kJH=HukRekwM-GZg@mail.gmail.com Discussion: https://postgr.es/m/20201231134736.GA25392@alvherre.pgsql
2022-03-28 16:45:58 +02:00
&merge;
&move;
&notify;
&prepare;
&prepareTransaction;
&reassignOwned;
&refreshMaterializedView;
&reindex;
&releaseSavepoint;
&reset;
&revoke;
&rollback;
&rollbackPrepared;
&rollbackTo;
&savepoint;
&securityLabel;
&select;
&selectInto;
&set;
&setConstraints;
&setRole;
2001-05-08 23:06:43 +02:00
&setSessionAuth;
&setTransaction;
&show;
&startTransaction;
&truncate;
&unlisten;
&update;
&vacuum;
&values;
</reference>
1998-05-13 07:34:39 +02:00
<reference id="reference-client">
<title>PostgreSQL Client Applications</title>
1998-05-13 07:34:39 +02:00
<partintro>
<para>
This part contains reference information for
<productname>PostgreSQL</productname> client applications and
utilities. Not all of these commands are of general utility; some
might require special privileges. The common feature of these
applications is that they can be run on any host, independent of
where the database server resides.
</para>
<para>
When specified on the command line, user and database names have
their case preserved &mdash; the presence of spaces or special
characters might require quoting. Table names and other identifiers
do not have their case preserved, except where documented, and
might require quoting.
</para>
</partintro>
&clusterdb;
&createdb;
&createuser;
&dropdb;
&dropuser;
&ecpgRef;
&pgamcheck;
&pgBasebackup;
&pgbench;
&pgCombinebackup;
&pgConfig;
&pgDump;
&pgDumpall;
&pgIsready;
&pgReceivewal;
&pgRecvlogical;
&pgRestore;
&pgVerifyBackup;
&psqlRef;
&reindexdb;
&vacuumdb;
</reference>
<reference id="reference-server">
<title>PostgreSQL Server Applications</title>
<partintro>
<para>
This part contains reference information for
<productname>PostgreSQL</productname> server applications and
support utilities. These commands can only be run usefully on the
host where the database server resides. Other utility programs
are listed in <xref linkend="reference-client"/>.
</para>
</partintro>
&initdb;
&pgarchivecleanup;
&pgChecksums;
&pgControldata;
pg_createsubscriber: creates a new logical replica from a standby server It must be run on the target server and should be able to connect to the source server (publisher) and the target server (subscriber). All tables in the specified database(s) are included in the logical replication setup. A pair of publication and subscription objects are created for each database. The main advantage of pg_createsubscriber over the common logical replication setup is the initial data copy. It also reduces the catchup phase. Some prerequisites must be met to successfully run it. It is basically the logical replication requirements. It starts creating a publication using FOR ALL TABLES and a replication slot for each specified database. Write recovery parameters into the target data directory and start the target server. It specifies the LSN of the last replication slot (replication start point) up to which the recovery will proceed. Wait until the target server is promoted. Create one subscription per specified database (using publication and replication slot created in a previous step) on the target server. Set the replication progress to the replication start point for each subscription. Enable the subscription for each specified database on the target server. And finally, change the system identifier on the target server. Author: Euler Taveira <euler.taveira@enterprisedb.com> Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com> Reviewed-by: Vignesh C <vignesh21@gmail.com> Reviewed-by: Shubham Khanna <khannashubham1197@gmail.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://www.postgresql.org/message-id/flat/5ac50071-f2ed-4ace-a8fd-b892cffd33eb@www.fastmail.com
2024-03-25 12:30:55 +01:00
&pgCreateSubscriber;
&pgCtl;
&pgResetwal;
&pgRewind;
&pgtestfsync;
&pgtesttiming;
&pgupgrade;
&pgwaldump;
&pgwalsummary;
&postgres;
</reference>
1998-05-13 07:34:39 +02:00
</part>