2010-09-20 22:08:53 +02:00
<!-- doc/src/sgml/catalogs.sgml -->
2000-11-29 21:15:59 +01:00
<!--
Documentation of the system catalogs, directed toward PostgreSQL developers
-->
<chapter id="catalogs">
<title>System Catalogs</title>
<para>
The system catalogs are the place where a relational database
management system stores schema metadata, such as information about
tables and columns, and internal bookkeeping information.
<productname>PostgreSQL</productname>'s system catalogs are regular
tables. You can drop and recreate the tables, add columns, insert
and update values, and severely mess up your system that way.
2003-04-15 15:23:35 +02:00
Normally, one should not change the system catalogs by hand, there
2016-06-07 20:15:42 +02:00
are normally SQL commands to do that. (For example, <command>CREATE
2000-11-29 21:15:59 +01:00
DATABASE</command> inserts a row into the
2004-11-15 07:32:15 +01:00
<structname>pg_database</structname> catalog — and actually
2000-11-29 21:15:59 +01:00
creates the database on disk.) There are some exceptions for
2016-06-07 20:15:42 +02:00
particularly esoteric operations, but many of those have been made
available as SQL commands over time, and so the need for direct manipulation
of the system catalogs is ever decreasing.
2003-04-15 15:23:35 +02:00
</para>
<sect1 id="catalogs-overview">
<title>Overview</title>
<para>
2017-11-23 15:39:47 +01:00
<xref linkend="catalog-table"/> lists the system catalogs.
2003-04-15 15:23:35 +02:00
More detailed documentation of each catalog follows below.
2000-11-29 21:15:59 +01:00
</para>
2003-04-15 15:23:35 +02:00
2002-10-14 06:29:23 +02:00
<para>
Most system catalogs are copied from the template database during
2003-04-15 15:23:35 +02:00
database creation and are thereafter database-specific. A few
catalogs are physically shared across all databases in a cluster;
2005-01-06 00:42:03 +01:00
these are noted in the descriptions of the individual catalogs.
2002-10-14 06:29:23 +02:00
</para>
2000-11-29 21:15:59 +01:00
2003-04-15 15:23:35 +02:00
<table id="catalog-table">
2000-11-29 21:15:59 +01:00
<title>System Catalogs</title>
<tgroup cols="2">
<thead>
<row>
<entry>Catalog Name</entry>
<entry>Purpose</entry>
</row>
</thead>
<tbody>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-aggregate"><structname>pg_aggregate</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>aggregate functions</entry>
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-am"><structname>pg_am</structname></link></entry>
2019-05-29 17:37:37 +02:00
<entry>relation access methods</entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-amop"><structname>pg_amop</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>access method operators</entry>
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link></entry>
2018-08-15 17:01:39 +02:00
<entry>access method support functions</entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-attrdef"><structname>pg_attrdef</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>column default values</entry>
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link></entry>
<entry>table columns (<quote>attributes</quote>)</entry>
2000-11-29 21:15:59 +01:00
</row>
2005-06-28 07:09:14 +02:00
<row>
<entry><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link></entry>
<entry>authorization identifiers (roles)</entry>
</row>
<row>
<entry><link linkend="catalog-pg-auth-members"><structname>pg_auth_members</structname></link></entry>
<entry>authorization identifier membership relationships</entry>
</row>
2002-07-22 22:23:19 +02:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-cast"><structname>pg_cast</structname></link></entry>
2002-07-22 22:23:19 +02:00
<entry>casts (data type conversions)</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-class"><structname>pg_class</structname></link></entry>
2005-01-06 00:42:03 +01:00
<entry>tables, indexes, sequences, views (<quote>relations</quote>)</entry>
2000-11-29 21:15:59 +01:00
</row>
2002-07-12 20:43:19 +02:00
<row>
2013-12-30 19:27:51 +01:00
<entry><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link></entry>
<entry>collations (locale information)</entry>
2002-07-12 20:43:19 +02:00
</row>
2011-02-08 22:04:18 +01:00
<row>
2013-12-30 19:27:51 +01:00
<entry><link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link></entry>
<entry>check constraints, unique constraints, primary key constraints, foreign key constraints</entry>
2011-02-08 22:04:18 +01:00
</row>
2002-07-24 07:51:56 +02:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-conversion"><structname>pg_conversion</structname></link></entry>
2002-07-24 07:51:56 +02:00
<entry>encoding conversion information</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-database"><structname>pg_database</structname></link></entry>
2001-10-16 00:47:47 +02:00
<entry>databases within this database cluster</entry>
2000-11-29 21:15:59 +01:00
</row>
2010-09-17 20:49:54 +02:00
<row>
<entry><link linkend="catalog-pg-db-role-setting"><structname>pg_db_role_setting</structname></link></entry>
<entry>per-role and per-database settings</entry>
</row>
2009-10-05 21:24:49 +02:00
<row>
<entry><link linkend="catalog-pg-default-acl"><structname>pg_default_acl</structname></link></entry>
<entry>default privileges for object types</entry>
</row>
2002-07-12 20:43:19 +02:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-depend"><structname>pg_depend</structname></link></entry>
2002-07-12 20:43:19 +02:00
<entry>dependencies between database objects</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-description"><structname>pg_description</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>descriptions or comments on database objects</entry>
</row>
2007-04-02 05:49:42 +02:00
<row>
<entry><link linkend="catalog-pg-enum"><structname>pg_enum</structname></link></entry>
<entry>enum label and value definitions</entry>
</row>
2012-07-18 16:16:16 +02:00
<row>
<entry><link linkend="catalog-pg-event-trigger"><structname>pg_event_trigger</structname></link></entry>
<entry>event triggers</entry>
</row>
2011-02-08 22:08:41 +01:00
<row>
<entry><link linkend="catalog-pg-extension"><structname>pg_extension</structname></link></entry>
<entry>installed extensions</entry>
</row>
2008-12-19 17:25:19 +01:00
<row>
<entry><link linkend="catalog-pg-foreign-data-wrapper"><structname>pg_foreign_data_wrapper</structname></link></entry>
<entry>foreign-data wrapper definitions</entry>
</row>
<row>
<entry><link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link></entry>
<entry>foreign server definitions</entry>
</row>
2011-01-02 05:48:11 +01:00
<row>
<entry><link linkend="catalog-pg-foreign-table"><structname>pg_foreign_table</structname></link></entry>
<entry>additional foreign table information</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-index"><structname>pg_index</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>additional index information</entry>
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-inherits"><structname>pg_inherits</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>table inheritance hierarchy</entry>
</row>
2016-04-07 03:45:32 +02:00
<row>
<entry><link linkend="catalog-pg-init-privs"><structname>pg_init_privs</structname></link></entry>
<entry>object initial privileges</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-language"><structname>pg_language</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>languages for writing functions</entry>
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-largeobject"><structname>pg_largeobject</structname></link></entry>
2009-12-11 04:34:57 +01:00
<entry>data pages for large objects</entry>
</row>
<row>
<entry><link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</structname></link></entry>
<entry>metadata for large objects</entry>
2000-11-29 21:15:59 +01:00
</row>
2002-03-22 22:34:44 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link></entry>
<entry>schemas</entry>
2002-03-22 22:34:44 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link></entry>
2006-12-23 01:43:13 +01:00
<entry>access method operator classes</entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>operators</entry>
</row>
2006-12-23 01:43:13 +01:00
<row>
<entry><link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link></entry>
<entry>access method operator families</entry>
</row>
2022-04-06 19:24:33 +02:00
<row>
<entry><link linkend="catalog-pg-parameter-acl"><structname>pg_parameter_acl</structname></link></entry>
<entry>configuration parameters for which privileges have been granted</entry>
</row>
2005-09-08 22:07:42 +02:00
<row>
2017-05-15 01:15:52 +02:00
<entry><link linkend="catalog-pg-partitioned-table"><structname>pg_partitioned_table</structname></link></entry>
<entry>information about partition key of tables</entry>
2005-09-08 22:07:42 +02:00
</row>
2015-01-24 22:16:22 +01:00
<row>
<entry><link linkend="catalog-pg-policy"><structname>pg_policy</structname></link></entry>
<entry>row-security policies</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>functions and procedures</entry>
</row>
2017-01-19 18:00:00 +01:00
<row>
<entry><link linkend="catalog-pg-publication"><structname>pg_publication</structname></link></entry>
<entry>publications for logical replication</entry>
</row>
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
<row>
<entry><link linkend="catalog-pg-publication-namespace"><structname>pg_publication_namespace</structname></link></entry>
<entry>schema to publication mapping</entry>
</row>
2017-01-19 18:00:00 +01:00
<row>
<entry><link linkend="catalog-pg-publication-rel"><structname>pg_publication_rel</structname></link></entry>
<entry>relation to publication mapping</entry>
</row>
2011-11-03 12:16:28 +01:00
<row>
<entry><link linkend="catalog-pg-range"><structname>pg_range</structname></link></entry>
<entry>information about range types</entry>
</row>
Introduce replication progress tracking infrastructure.
When implementing a replication solution ontop of logical decoding, two
related problems exist:
* How to safely keep track of replication progress
* How to change replication behavior, based on the origin of a row;
e.g. to avoid loops in bi-directional replication setups
The solution to these problems, as implemented here, consist out of
three parts:
1) 'replication origins', which identify nodes in a replication setup.
2) 'replication progress tracking', which remembers, for each
replication origin, how far replay has progressed in a efficient and
crash safe manner.
3) The ability to filter out changes performed on the behest of a
replication origin during logical decoding; this allows complex
replication topologies. E.g. by filtering all replayed changes out.
Most of this could also be implemented in "userspace", e.g. by inserting
additional rows contain origin information, but that ends up being much
less efficient and more complicated. We don't want to require various
replication solutions to reimplement logic for this independently. The
infrastructure is intended to be generic enough to be reusable.
This infrastructure also replaces the 'nodeid' infrastructure of commit
timestamps. It is intended to provide all the former capabilities,
except that there's only 2^16 different origins; but now they integrate
with logical decoding. Additionally more functionality is accessible via
SQL. Since the commit timestamp infrastructure has also been introduced
in 9.5 (commit 73c986add) changing the API is not a problem.
For now the number of origins for which the replication progress can be
tracked simultaneously is determined by the max_replication_slots
GUC. That GUC is not a perfect match to configure this, but there
doesn't seem to be sufficient reason to introduce a separate new one.
Bumps both catversion and wal page magic.
Author: Andres Freund, with contributions from Petr Jelinek and Craig Ringer
Reviewed-By: Heikki Linnakangas, Petr Jelinek, Robert Haas, Steve Singer
Discussion: 20150216002155.GI15326@awork2.anarazel.de,
20140923182422.GA15776@alap3.anarazel.de,
20131114172632.GE7522@alap2.anarazel.de
2015-04-29 19:30:53 +02:00
<row>
<entry><link linkend="catalog-pg-replication-origin"><structname>pg_replication_origin</structname></link></entry>
<entry>registered replication origins</entry>
</row>
<row>
2016-05-05 18:33:12 +02:00
<entry><link linkend="catalog-pg-rewrite"><structname>pg_rewrite</structname></link></entry>
<entry>query rewrite rules</entry>
2014-02-01 04:45:17 +01:00
</row>
2010-09-28 02:55:27 +02:00
<row>
<entry><link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link></entry>
<entry>security labels on database objects</entry>
</row>
2016-12-20 18:00:00 +01:00
<row>
<entry><link linkend="catalog-pg-sequence"><structname>pg_sequence</structname></link></entry>
<entry>information about sequences</entry>
</row>
2005-07-07 22:40:02 +02:00
<row>
<entry><link linkend="catalog-pg-shdepend"><structname>pg_shdepend</structname></link></entry>
<entry>dependencies on shared objects</entry>
</row>
2006-02-12 04:22:21 +01:00
<row>
<entry><link linkend="catalog-pg-shdescription"><structname>pg_shdescription</structname></link></entry>
<entry>comments on shared objects</entry>
</row>
2011-07-20 19:18:24 +02:00
<row>
<entry><link linkend="catalog-pg-shseclabel"><structname>pg_shseclabel</structname></link></entry>
<entry>security labels on shared database objects</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link></entry>
<entry>planner statistics</entry>
2000-11-29 21:15:59 +01:00
</row>
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
<row>
<entry><link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link></entry>
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
<entry>extended planner statistics (definition)</entry>
</row>
<row>
<entry><link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link></entry>
<entry>extended planner statistics (built statistics)</entry>
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
</row>
2017-01-19 18:00:00 +01:00
<row>
<entry><link linkend="catalog-pg-subscription"><structname>pg_subscription</structname></link></entry>
<entry>logical replication subscriptions</entry>
</row>
2017-03-23 13:36:36 +01:00
<row>
<entry><link linkend="catalog-pg-subscription-rel"><structname>pg_subscription_rel</structname></link></entry>
<entry>relation state for subscriptions</entry>
</row>
2004-06-18 08:14:31 +02:00
<row>
<entry><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link></entry>
<entry>tablespaces within this database cluster</entry>
</row>
2015-04-26 16:33:14 +02:00
<row>
<entry><link linkend="catalog-pg-transform"><structname>pg_transform</structname></link></entry>
<entry>transforms (data type to procedural language conversions)</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-trigger"><structname>pg_trigger</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>triggers</entry>
</row>
2007-10-01 23:10:40 +02:00
<row>
<entry><link linkend="catalog-pg-ts-config"><structname>pg_ts_config</structname></link></entry>
<entry>text search configurations</entry>
</row>
<row>
<entry><link linkend="catalog-pg-ts-config-map"><structname>pg_ts_config_map</structname></link></entry>
<entry>text search configurations' token mappings</entry>
</row>
<row>
<entry><link linkend="catalog-pg-ts-dict"><structname>pg_ts_dict</structname></link></entry>
<entry>text search dictionaries</entry>
</row>
<row>
<entry><link linkend="catalog-pg-ts-parser"><structname>pg_ts_parser</structname></link></entry>
<entry>text search parsers</entry>
</row>
<row>
<entry><link linkend="catalog-pg-ts-template"><structname>pg_ts_template</structname></link></entry>
<entry>text search templates</entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-type"><structname>pg_type</structname></link></entry>
2000-11-29 21:15:59 +01:00
<entry>data types</entry>
</row>
2008-12-19 17:25:19 +01:00
<row>
<entry><link linkend="catalog-pg-user-mapping"><structname>pg_user_mapping</structname></link></entry>
<entry>mappings of users to foreign servers</entry>
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-aggregate">
2003-04-15 15:23:35 +02:00
<title><structname>pg_aggregate</structname></title>
<indexterm zone="catalog-pg-aggregate">
<primary>pg_aggregate</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_aggregate</structname> stores information about
2000-11-29 21:15:59 +01:00
aggregate functions. An aggregate function is a function that
2001-05-07 02:43:27 +02:00
operates on a set of values (typically one column from each row
2000-11-29 21:15:59 +01:00
that matches a query condition) and returns a single value computed
from all these values. Typical aggregate functions are
<function>sum</function>, <function>count</function>, and
2002-04-11 22:00:18 +02:00
<function>max</function>. Each entry in
<structname>pg_aggregate</structname> is an extension of an entry
2020-09-03 13:15:53 +02:00
in <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.
The <structname>pg_proc</structname> entry carries the aggregate's name,
input and output data types, and other information that is similar to
ordinary functions.
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_aggregate</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2000-11-29 21:15:59 +01:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggfnoid</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
<structname>pg_proc</structname> OID of the aggregate function
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggkind</structfield> <type>char</type>
</para>
<para>
Aggregate kind:
2017-10-09 03:44:17 +02:00
<literal>n</literal> for <quote>normal</quote> aggregates,
<literal>o</literal> for <quote>ordered-set</quote> aggregates, or
<literal>h</literal> for <quote>hypothetical-set</quote> aggregates
2020-05-14 05:03:39 +02:00
</para></entry>
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
</row>
2020-05-14 05:03:39 +02:00
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggnumdirectargs</structfield> <type>int2</type>
</para>
<para>
Number of direct (non-aggregated) arguments of an ordered-set or
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
hypothetical-set aggregate, counting a variadic array as one argument.
2017-10-09 03:44:17 +02:00
If equal to <structfield>pronargs</structfield>, the aggregate must be variadic
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
and the variadic array describes the aggregated arguments as well as
the final direct arguments.
2020-05-14 05:03:39 +02:00
Always zero for normal aggregates.
</para></entry>
Support ordered-set (WITHIN GROUP) aggregates.
This patch introduces generic support for ordered-set and hypothetical-set
aggregate functions, as well as implementations of the instances defined in
SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
percent_rank(), cume_dist()). We also added mode() though it is not in the
spec, as well as versions of percentile_cont() and percentile_disc() that
can compute multiple percentile values in one pass over the data.
Unlike the original submission, this patch puts full control of the sorting
process in the hands of the aggregate's support functions. To allow the
support functions to find out how they're supposed to sort, a new API
function AggGetAggref() is added to nodeAgg.c. This allows retrieval of
the aggregate call's Aggref node, which may have other uses beyond the
immediate need. There is also support for ordered-set aggregates to
install cleanup callback functions, so that they can be sure that
infrastructure such as tuplesort objects gets cleaned up.
In passing, make some fixes in the recently-added support for variadic
aggregates, and make some editorial adjustments in the recent FILTER
additions for aggregates. Also, simplify use of IsBinaryCoercible() by
allowing it to succeed whenever the target type is ANY or ANYELEMENT.
It was inconsistent that it dealt with other polymorphic target types
but not these.
Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
and rather heavily editorialized upon by Tom Lane
2013-12-23 22:11:35 +01:00
</row>
2020-05-14 05:03:39 +02:00
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggtransfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Transition function
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggfinalfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Final function (zero if none)
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-03-24 17:59:18 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggcombinefn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Combine function (zero if none)
</para></entry>
2016-03-24 17:59:18 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-03-29 21:04:05 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggserialfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Serialization function (zero if none)
</para></entry>
2016-03-29 21:04:05 +02:00
</row>
2020-05-14 05:03:39 +02:00
2016-03-29 21:04:05 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggdeserialfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Deserialization function (zero if none)
</para></entry>
2016-03-29 21:04:05 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-04-12 17:58:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggmtransfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Forward transition function for moving-aggregate mode (zero if none)
</para></entry>
2014-04-12 17:58:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-04-12 17:58:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggminvtransfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Inverse transition function for moving-aggregate mode (zero if none)
</para></entry>
2014-04-12 17:58:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-04-12 17:58:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggmfinalfn</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Final function for moving-aggregate mode (zero if none)
</para></entry>
2014-04-12 17:58:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
Allow polymorphic aggregates to have non-polymorphic state data types.
Before 9.4, such an aggregate couldn't be declared, because its final
function would have to have polymorphic result type but no polymorphic
argument, which CREATE FUNCTION would quite properly reject. The
ordered-set-aggregate patch found a workaround: allow the final function
to be declared as accepting additional dummy arguments that have types
matching the aggregate's regular input arguments. However, we failed
to notice that this problem applies just as much to regular aggregates,
despite the fact that we had a built-in regular aggregate array_agg()
that was known to be undeclarable in SQL because its final function
had an illegal signature. So what we should have done, and what this
patch does, is to decouple the extra-dummy-arguments behavior from
ordered-set aggregates and make it generally available for all aggregate
declarations. We have to put this into 9.4 rather than waiting till
later because it slightly alters the rules for declaring ordered-set
aggregates.
The patch turned out a bit bigger than I'd hoped because it proved
necessary to record the extra-arguments option in a new pg_aggregate
column. I'd thought we could just look at the final function's pronargs
at runtime, but that didn't work well for variadic final functions.
It's probably just as well though, because it simplifies life for pg_dump
to record the option explicitly.
While at it, fix array_agg() to have a valid final-function signature,
and add an opr_sanity test to notice future deviations from polymorphic
consistency. I also marked the percentile_cont() aggregates as not
needing extra arguments, since they don't.
2014-04-24 01:17:31 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggfinalextra</structfield> <type>bool</type>
</para>
<para>
True to pass extra dummy arguments to <structfield>aggfinalfn</structfield>
</para></entry>
Allow polymorphic aggregates to have non-polymorphic state data types.
Before 9.4, such an aggregate couldn't be declared, because its final
function would have to have polymorphic result type but no polymorphic
argument, which CREATE FUNCTION would quite properly reject. The
ordered-set-aggregate patch found a workaround: allow the final function
to be declared as accepting additional dummy arguments that have types
matching the aggregate's regular input arguments. However, we failed
to notice that this problem applies just as much to regular aggregates,
despite the fact that we had a built-in regular aggregate array_agg()
that was known to be undeclarable in SQL because its final function
had an illegal signature. So what we should have done, and what this
patch does, is to decouple the extra-dummy-arguments behavior from
ordered-set aggregates and make it generally available for all aggregate
declarations. We have to put this into 9.4 rather than waiting till
later because it slightly alters the rules for declaring ordered-set
aggregates.
The patch turned out a bit bigger than I'd hoped because it proved
necessary to record the extra-arguments option in a new pg_aggregate
column. I'd thought we could just look at the final function's pronargs
at runtime, but that didn't work well for variadic final functions.
It's probably just as well though, because it simplifies life for pg_dump
to record the option explicitly.
While at it, fix array_agg() to have a valid final-function signature,
and add an opr_sanity test to notice future deviations from polymorphic
consistency. I also marked the percentile_cont() aggregates as not
needing extra arguments, since they don't.
2014-04-24 01:17:31 +02:00
</row>
2020-05-14 05:03:39 +02:00
Allow polymorphic aggregates to have non-polymorphic state data types.
Before 9.4, such an aggregate couldn't be declared, because its final
function would have to have polymorphic result type but no polymorphic
argument, which CREATE FUNCTION would quite properly reject. The
ordered-set-aggregate patch found a workaround: allow the final function
to be declared as accepting additional dummy arguments that have types
matching the aggregate's regular input arguments. However, we failed
to notice that this problem applies just as much to regular aggregates,
despite the fact that we had a built-in regular aggregate array_agg()
that was known to be undeclarable in SQL because its final function
had an illegal signature. So what we should have done, and what this
patch does, is to decouple the extra-dummy-arguments behavior from
ordered-set aggregates and make it generally available for all aggregate
declarations. We have to put this into 9.4 rather than waiting till
later because it slightly alters the rules for declaring ordered-set
aggregates.
The patch turned out a bit bigger than I'd hoped because it proved
necessary to record the extra-arguments option in a new pg_aggregate
column. I'd thought we could just look at the final function's pronargs
at runtime, but that didn't work well for variadic final functions.
It's probably just as well though, because it simplifies life for pg_dump
to record the option explicitly.
While at it, fix array_agg() to have a valid final-function signature,
and add an opr_sanity test to notice future deviations from polymorphic
consistency. I also marked the percentile_cont() aggregates as not
needing extra arguments, since they don't.
2014-04-24 01:17:31 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggmfinalextra</structfield> <type>bool</type>
</para>
<para>
True to pass extra dummy arguments to <structfield>aggmfinalfn</structfield>
</para></entry>
Allow polymorphic aggregates to have non-polymorphic state data types.
Before 9.4, such an aggregate couldn't be declared, because its final
function would have to have polymorphic result type but no polymorphic
argument, which CREATE FUNCTION would quite properly reject. The
ordered-set-aggregate patch found a workaround: allow the final function
to be declared as accepting additional dummy arguments that have types
matching the aggregate's regular input arguments. However, we failed
to notice that this problem applies just as much to regular aggregates,
despite the fact that we had a built-in regular aggregate array_agg()
that was known to be undeclarable in SQL because its final function
had an illegal signature. So what we should have done, and what this
patch does, is to decouple the extra-dummy-arguments behavior from
ordered-set aggregates and make it generally available for all aggregate
declarations. We have to put this into 9.4 rather than waiting till
later because it slightly alters the rules for declaring ordered-set
aggregates.
The patch turned out a bit bigger than I'd hoped because it proved
necessary to record the extra-arguments option in a new pg_aggregate
column. I'd thought we could just look at the final function's pronargs
at runtime, but that didn't work well for variadic final functions.
It's probably just as well though, because it simplifies life for pg_dump
to record the option explicitly.
While at it, fix array_agg() to have a valid final-function signature,
and add an opr_sanity test to notice future deviations from polymorphic
consistency. I also marked the percentile_cont() aggregates as not
needing extra arguments, since they don't.
2014-04-24 01:17:31 +02:00
</row>
2020-05-14 05:03:39 +02:00
Explicitly track whether aggregate final functions modify transition state.
Up to now, there's been hard-wired assumptions that normal aggregates'
final functions never modify their transition states, while ordered-set
aggregates' final functions always do. This has always been a bit
limiting, and in particular it's getting in the way of improving the
built-in ordered-set aggregates to allow merging of transition states.
Therefore, let's introduce catalog and CREATE AGGREGATE infrastructure
that lets the finalfn's behavior be declared explicitly.
There are now three possibilities for the finalfn behavior: it's purely
read-only, it trashes the transition state irrecoverably, or it changes
the state in such a way that no more transfn calls are possible but the
state can still be passed to other, compatible finalfns. There are no
examples of this third case today, but we'll shortly make the built-in
OSAs act like that.
This change allows user-defined aggregates to explicitly disclaim support
for use as window functions, and/or to prevent transition state merging,
if their implementations cannot handle that. While it was previously
possible to handle the window case with a run-time error check, there was
not any way to prevent transition state merging, which in retrospect is
something commit 804163bc2 should have provided for. But better late
than never.
In passing, split out pg_aggregate.c's extern function declarations into
a new header file pg_aggregate_fn.h, similarly to what we've done for
some other catalog headers, so that pg_aggregate.h itself can be safe
for frontend files to include. This lets pg_dump use the symbolic
names for relevant constants.
Discussion: https://postgr.es/m/4834.1507849699@sss.pgh.pa.us
2017-10-14 21:21:39 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggfinalmodify</structfield> <type>char</type>
</para>
<para>
Whether <structfield>aggfinalfn</structfield> modifies the
Explicitly track whether aggregate final functions modify transition state.
Up to now, there's been hard-wired assumptions that normal aggregates'
final functions never modify their transition states, while ordered-set
aggregates' final functions always do. This has always been a bit
limiting, and in particular it's getting in the way of improving the
built-in ordered-set aggregates to allow merging of transition states.
Therefore, let's introduce catalog and CREATE AGGREGATE infrastructure
that lets the finalfn's behavior be declared explicitly.
There are now three possibilities for the finalfn behavior: it's purely
read-only, it trashes the transition state irrecoverably, or it changes
the state in such a way that no more transfn calls are possible but the
state can still be passed to other, compatible finalfns. There are no
examples of this third case today, but we'll shortly make the built-in
OSAs act like that.
This change allows user-defined aggregates to explicitly disclaim support
for use as window functions, and/or to prevent transition state merging,
if their implementations cannot handle that. While it was previously
possible to handle the window case with a run-time error check, there was
not any way to prevent transition state merging, which in retrospect is
something commit 804163bc2 should have provided for. But better late
than never.
In passing, split out pg_aggregate.c's extern function declarations into
a new header file pg_aggregate_fn.h, similarly to what we've done for
some other catalog headers, so that pg_aggregate.h itself can be safe
for frontend files to include. This lets pg_dump use the symbolic
names for relevant constants.
Discussion: https://postgr.es/m/4834.1507849699@sss.pgh.pa.us
2017-10-14 21:21:39 +02:00
transition state value:
<literal>r</literal> if it is read-only,
<literal>s</literal> if the <structfield>aggtransfn</structfield>
cannot be applied after the <structfield>aggfinalfn</structfield>, or
<literal>w</literal> if it writes on the value
2020-05-14 05:03:39 +02:00
</para></entry>
Explicitly track whether aggregate final functions modify transition state.
Up to now, there's been hard-wired assumptions that normal aggregates'
final functions never modify their transition states, while ordered-set
aggregates' final functions always do. This has always been a bit
limiting, and in particular it's getting in the way of improving the
built-in ordered-set aggregates to allow merging of transition states.
Therefore, let's introduce catalog and CREATE AGGREGATE infrastructure
that lets the finalfn's behavior be declared explicitly.
There are now three possibilities for the finalfn behavior: it's purely
read-only, it trashes the transition state irrecoverably, or it changes
the state in such a way that no more transfn calls are possible but the
state can still be passed to other, compatible finalfns. There are no
examples of this third case today, but we'll shortly make the built-in
OSAs act like that.
This change allows user-defined aggregates to explicitly disclaim support
for use as window functions, and/or to prevent transition state merging,
if their implementations cannot handle that. While it was previously
possible to handle the window case with a run-time error check, there was
not any way to prevent transition state merging, which in retrospect is
something commit 804163bc2 should have provided for. But better late
than never.
In passing, split out pg_aggregate.c's extern function declarations into
a new header file pg_aggregate_fn.h, similarly to what we've done for
some other catalog headers, so that pg_aggregate.h itself can be safe
for frontend files to include. This lets pg_dump use the symbolic
names for relevant constants.
Discussion: https://postgr.es/m/4834.1507849699@sss.pgh.pa.us
2017-10-14 21:21:39 +02:00
</row>
2020-05-14 05:03:39 +02:00
Explicitly track whether aggregate final functions modify transition state.
Up to now, there's been hard-wired assumptions that normal aggregates'
final functions never modify their transition states, while ordered-set
aggregates' final functions always do. This has always been a bit
limiting, and in particular it's getting in the way of improving the
built-in ordered-set aggregates to allow merging of transition states.
Therefore, let's introduce catalog and CREATE AGGREGATE infrastructure
that lets the finalfn's behavior be declared explicitly.
There are now three possibilities for the finalfn behavior: it's purely
read-only, it trashes the transition state irrecoverably, or it changes
the state in such a way that no more transfn calls are possible but the
state can still be passed to other, compatible finalfns. There are no
examples of this third case today, but we'll shortly make the built-in
OSAs act like that.
This change allows user-defined aggregates to explicitly disclaim support
for use as window functions, and/or to prevent transition state merging,
if their implementations cannot handle that. While it was previously
possible to handle the window case with a run-time error check, there was
not any way to prevent transition state merging, which in retrospect is
something commit 804163bc2 should have provided for. But better late
than never.
In passing, split out pg_aggregate.c's extern function declarations into
a new header file pg_aggregate_fn.h, similarly to what we've done for
some other catalog headers, so that pg_aggregate.h itself can be safe
for frontend files to include. This lets pg_dump use the symbolic
names for relevant constants.
Discussion: https://postgr.es/m/4834.1507849699@sss.pgh.pa.us
2017-10-14 21:21:39 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggmfinalmodify</structfield> <type>char</type>
</para>
<para>
Like <structfield>aggfinalmodify</structfield>, but for
Explicitly track whether aggregate final functions modify transition state.
Up to now, there's been hard-wired assumptions that normal aggregates'
final functions never modify their transition states, while ordered-set
aggregates' final functions always do. This has always been a bit
limiting, and in particular it's getting in the way of improving the
built-in ordered-set aggregates to allow merging of transition states.
Therefore, let's introduce catalog and CREATE AGGREGATE infrastructure
that lets the finalfn's behavior be declared explicitly.
There are now three possibilities for the finalfn behavior: it's purely
read-only, it trashes the transition state irrecoverably, or it changes
the state in such a way that no more transfn calls are possible but the
state can still be passed to other, compatible finalfns. There are no
examples of this third case today, but we'll shortly make the built-in
OSAs act like that.
This change allows user-defined aggregates to explicitly disclaim support
for use as window functions, and/or to prevent transition state merging,
if their implementations cannot handle that. While it was previously
possible to handle the window case with a run-time error check, there was
not any way to prevent transition state merging, which in retrospect is
something commit 804163bc2 should have provided for. But better late
than never.
In passing, split out pg_aggregate.c's extern function declarations into
a new header file pg_aggregate_fn.h, similarly to what we've done for
some other catalog headers, so that pg_aggregate.h itself can be safe
for frontend files to include. This lets pg_dump use the symbolic
names for relevant constants.
Discussion: https://postgr.es/m/4834.1507849699@sss.pgh.pa.us
2017-10-14 21:21:39 +02:00
the <structfield>aggmfinalfn</structfield>
2020-05-14 05:03:39 +02:00
</para></entry>
Explicitly track whether aggregate final functions modify transition state.
Up to now, there's been hard-wired assumptions that normal aggregates'
final functions never modify their transition states, while ordered-set
aggregates' final functions always do. This has always been a bit
limiting, and in particular it's getting in the way of improving the
built-in ordered-set aggregates to allow merging of transition states.
Therefore, let's introduce catalog and CREATE AGGREGATE infrastructure
that lets the finalfn's behavior be declared explicitly.
There are now three possibilities for the finalfn behavior: it's purely
read-only, it trashes the transition state irrecoverably, or it changes
the state in such a way that no more transfn calls are possible but the
state can still be passed to other, compatible finalfns. There are no
examples of this third case today, but we'll shortly make the built-in
OSAs act like that.
This change allows user-defined aggregates to explicitly disclaim support
for use as window functions, and/or to prevent transition state merging,
if their implementations cannot handle that. While it was previously
possible to handle the window case with a run-time error check, there was
not any way to prevent transition state merging, which in retrospect is
something commit 804163bc2 should have provided for. But better late
than never.
In passing, split out pg_aggregate.c's extern function declarations into
a new header file pg_aggregate_fn.h, similarly to what we've done for
some other catalog headers, so that pg_aggregate.h itself can be safe
for frontend files to include. This lets pg_dump use the symbolic
names for relevant constants.
Discussion: https://postgr.es/m/4834.1507849699@sss.pgh.pa.us
2017-10-14 21:21:39 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-04-12 06:26:34 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggsortop</structfield> <type>oid</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Associated sort operator (zero if none)
</para></entry>
2005-04-12 06:26:34 +02:00
</row>
2020-05-14 05:03:39 +02:00
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggtranstype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type of the aggregate function's internal transition (state) data
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-11-16 22:03:40 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggtransspace</structfield> <type>int4</type>
</para>
<para>
Approximate average size (in bytes) of the transition state
data, or zero to use a default estimate
</para></entry>
2013-11-16 22:03:40 +01:00
</row>
2020-05-14 05:03:39 +02:00
2014-04-12 17:58:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggmtranstype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type of the aggregate function's internal transition (state)
data for moving-aggregate mode (zero if none)
</para></entry>
2014-04-12 17:58:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-04-12 17:58:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggmtransspace</structfield> <type>int4</type>
</para>
<para>
Approximate average size (in bytes) of the transition state data
for moving-aggregate mode, or zero to use a default estimate
</para></entry>
2014-04-12 17:58:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>agginitval</structfield> <type>text</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
The initial value of the transition state. This is a text
2001-09-06 04:07:42 +02:00
field containing the initial value in its external string
2010-08-17 06:37:21 +02:00
representation. If this field is null, the transition state
value starts out null.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2014-04-12 17:58:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>aggminitval</structfield> <type>text</type>
</para>
<para>
2014-04-12 17:58:53 +02:00
The initial value of the transition state for moving-aggregate mode.
This is a text field containing the initial value in its external
string representation. If this field is null, the transition state
value starts out null.
2020-05-14 05:03:39 +02:00
</para></entry>
2014-04-12 17:58:53 +02:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
<para>
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
New aggregate functions are registered with the <link
linkend="sql-createaggregate"><command>CREATE AGGREGATE</command></link>
2017-11-23 15:39:47 +01:00
command. See <xref linkend="xaggr"/> for more information about
2006-01-16 19:15:31 +01:00
writing aggregate functions and the meaning of the transition
functions, etc.
2000-11-29 21:15:59 +01:00
</para>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2002-07-30 07:24:56 +02:00
<sect1 id="catalog-pg-am">
2003-04-15 15:23:35 +02:00
<title><structname>pg_am</structname></title>
<indexterm zone="catalog-pg-am">
<primary>pg_am</primary>
</indexterm>
2002-07-30 07:24:56 +02:00
<para>
2016-08-14 00:31:14 +02:00
The catalog <structname>pg_am</structname> stores information about
relation access methods. There is one row for each access method supported
by the system.
2019-04-05 18:45:59 +02:00
Currently, only tables and indexes have access methods. The requirements for table
2019-04-04 02:37:00 +02:00
and index access methods are discussed in detail in <xref linkend="tableam"/> and
<xref linkend="indexam"/> respectively.
2002-07-30 07:24:56 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_am</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-30 07:24:56 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amname</structfield> <type>name</type>
</para>
<para>
Name of the access method
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amhandler</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
OID of a handler function that is responsible for supplying information
about the access method
2020-05-14 05:03:39 +02:00
</para></entry>
2006-07-04 00:45:41 +02:00
</row>
2016-08-14 00:31:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amtype</structfield> <type>char</type>
</para>
<para>
2019-04-04 02:37:00 +02:00
<literal>t</literal> = table (including materialized views),
<literal>i</literal> = index.
2020-05-14 05:03:39 +02:00
</para></entry>
2016-08-14 00:31:14 +02:00
</row>
2002-07-30 07:24:56 +02:00
</tbody>
</tgroup>
</table>
2016-08-14 00:31:14 +02:00
<note>
<para>
2017-10-09 03:44:17 +02:00
Before <productname>PostgreSQL</productname> 9.6, <structname>pg_am</structname>
2016-08-14 00:31:14 +02:00
contained many additional columns representing properties of index access
methods. That data is now only directly visible at the C code level.
However, <function>pg_index_column_has_property()</function> and related
functions have been added to allow SQL queries to inspect index access
2017-11-23 15:39:47 +01:00
method properties; see <xref linkend="functions-info-catalog-table"/>.
2016-08-14 00:31:14 +02:00
</para>
</note>
2002-07-30 07:24:56 +02:00
</sect1>
<sect1 id="catalog-pg-amop">
2003-04-15 15:23:35 +02:00
<title><structname>pg_amop</structname></title>
<indexterm zone="catalog-pg-amop">
<primary>pg_amop</primary>
</indexterm>
2002-07-30 07:24:56 +02:00
<para>
2006-12-23 01:43:13 +01:00
The catalog <structname>pg_amop</structname> stores information about
operators associated with access method operator families. There is one
2010-11-24 20:20:39 +01:00
row for each operator that is a member of an operator family. A family
2017-10-09 03:44:17 +02:00
member can be either a <firstterm>search</firstterm> operator or an
<firstterm>ordering</firstterm> operator. An operator
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
can appear in more than one family, but cannot appear in more than one
2010-11-24 20:20:39 +01:00
search position nor more than one ordering position within a family.
(It is allowed, though unlikely, for an operator to be used for both
search and ordering purposes.)
2002-07-30 07:24:56 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_amop</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-30 07:24:56 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amopfamily</structfield> <type>oid</type>
(references <link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The operator family this entry is for
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
2003-11-12 22:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amoplefttype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Left-hand input data type of operator
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amoprighttype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Right-hand input data type of operator
</para></entry>
2003-11-12 22:15:59 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amopstrategy</structfield> <type>int2</type>
</para>
<para>
Operator strategy number
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
2010-11-24 20:20:39 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amoppurpose</structfield> <type>char</type>
</para>
<para>
Operator purpose, either <literal>s</literal> for search or
<literal>o</literal> for ordering
</para></entry>
2010-11-24 20:20:39 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amopopr</structfield> <type>oid</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the operator
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
2006-12-23 01:43:13 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amopmethod</structfield> <type>oid</type>
(references <link linkend="catalog-pg-am"><structname>pg_am</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Index access method operator family is for
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
2010-11-24 20:20:39 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amopsortfamily</structfield> <type>oid</type>
(references <link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The B-tree operator family this entry sorts according to, if an
ordering operator; zero if a search operator
</para></entry>
2010-11-24 20:20:39 +01:00
</row>
2002-07-30 07:24:56 +02:00
</tbody>
</tgroup>
</table>
2010-11-24 20:20:39 +01:00
<para>
2017-10-09 03:44:17 +02:00
A <quote>search</quote> operator entry indicates that an index of this operator
2010-11-24 20:20:39 +01:00
family can be searched to find all rows satisfying
2017-10-09 03:44:17 +02:00
<literal>WHERE</literal>
<replaceable>indexed_column</replaceable>
<replaceable>operator</replaceable>
<replaceable>constant</replaceable>.
2014-07-17 04:20:15 +02:00
Obviously, such an operator must return <type>boolean</type>, and its left-hand input
2010-11-24 20:20:39 +01:00
type must match the index's column data type.
</para>
<para>
2017-10-09 03:44:17 +02:00
An <quote>ordering</quote> operator entry indicates that an index of this
2010-11-24 20:20:39 +01:00
operator family can be scanned to return rows in the order represented by
2017-10-09 03:44:17 +02:00
<literal>ORDER BY</literal>
<replaceable>indexed_column</replaceable>
<replaceable>operator</replaceable>
<replaceable>constant</replaceable>.
2010-11-24 20:20:39 +01:00
Such an operator could return any sortable data type, though again
its left-hand input type must match the index's column data type.
2017-10-09 03:44:17 +02:00
The exact semantics of the <literal>ORDER BY</literal> are specified by the
2010-11-24 20:20:39 +01:00
<structfield>amopsortfamily</structfield> column, which must reference
2014-07-17 04:20:15 +02:00
a B-tree operator family for the operator's result type.
2010-11-24 20:20:39 +01:00
</para>
<note>
<para>
At present, it's assumed that the sort order for an ordering operator
2014-07-17 04:20:15 +02:00
is the default for the referenced operator family, i.e., <literal>ASC NULLS
2017-10-09 03:44:17 +02:00
LAST</literal>. This might someday be relaxed by adding additional columns
2010-11-24 20:20:39 +01:00
to specify sort options explicitly.
</para>
</note>
2006-12-23 01:43:13 +01:00
<para>
2017-10-09 03:44:17 +02:00
An entry's <structfield>amopmethod</structfield> must match the
2020-06-22 06:40:04 +02:00
<structfield>opfmethod</structfield> of its containing operator family (including
2017-10-09 03:44:17 +02:00
<structfield>amopmethod</structfield> here is an intentional denormalization of the
2006-12-23 01:43:13 +01:00
catalog structure for performance reasons). Also,
2017-10-09 03:44:17 +02:00
<structfield>amoplefttype</structfield> and <structfield>amoprighttype</structfield> must match
the <structfield>oprleft</structfield> and <structfield>oprright</structfield> fields of the
2020-09-03 13:15:53 +02:00
referenced <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link> entry.
2006-12-23 01:43:13 +01:00
</para>
2002-07-30 07:24:56 +02:00
</sect1>
<sect1 id="catalog-pg-amproc">
2003-04-15 15:23:35 +02:00
<title><structname>pg_amproc</structname></title>
<indexterm zone="catalog-pg-amproc">
<primary>pg_amproc</primary>
</indexterm>
2002-07-30 07:24:56 +02:00
<para>
2006-12-23 01:43:13 +01:00
The catalog <structname>pg_amproc</structname> stores information about
2018-08-15 17:01:39 +02:00
support functions associated with access method operator families. There
is one row for each support function belonging to an operator family.
2002-07-30 07:24:56 +02:00
</para>
<table>
2003-04-15 15:23:35 +02:00
<title><structname>pg_amproc</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-30 07:24:56 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amprocfamily</structfield> <type>oid</type>
(references <link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The operator family this entry is for
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amproclefttype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Left-hand input data type of associated operator
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
2003-11-12 22:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amprocrighttype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Right-hand input data type of associated operator
</para></entry>
2003-11-12 22:15:59 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amprocnum</structfield> <type>int2</type>
</para>
<para>
Support function number
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>amproc</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the function
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
</tbody>
</tgroup>
</table>
2006-12-23 01:43:13 +01:00
<para>
The usual interpretation of the
2017-10-09 03:44:17 +02:00
<structfield>amproclefttype</structfield> and <structfield>amprocrighttype</structfield> fields
2006-12-23 01:43:13 +01:00
is that they identify the left and right input types of the operator(s)
2018-08-15 17:01:39 +02:00
that a particular support function supports. For some access methods
these match the input data type(s) of the support function itself, for
others not. There is a notion of <quote>default</quote> support functions for
2017-10-09 03:44:17 +02:00
an index, which are those with <structfield>amproclefttype</structfield> and
<structfield>amprocrighttype</structfield> both equal to the index operator class's
<structfield>opcintype</structfield>.
2006-12-23 01:43:13 +01:00
</para>
2002-07-30 07:24:56 +02:00
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-attrdef">
2003-04-15 15:23:35 +02:00
<title><structname>pg_attrdef</structname></title>
<indexterm zone="catalog-pg-attrdef">
<primary>pg_attrdef</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2018-10-29 08:38:54 +01:00
The catalog <structname>pg_attrdef</structname> stores column default
values. The main information about columns is stored in
<link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.
Only columns for which a default value has been explicitly set will have
an entry here.
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_attrdef</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>adrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table this column belongs to
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>adnum</structfield> <type>int2</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
The number of the column
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>adbin</structfield> <type>pg_node_tree</type>
</para>
<para>
The column default value, in <function>nodeToString()</function>
representation. Use <literal>pg_get_expr(adbin, adrelid)</literal> to
convert it to an SQL expression.
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-attribute">
2003-04-15 15:23:35 +02:00
<title><structname>pg_attribute</structname></title>
<indexterm zone="catalog-pg-attribute">
<primary>pg_attribute</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_attribute</structname> stores information about
2000-11-29 21:15:59 +01:00
table columns. There will be exactly one
<structname>pg_attribute</structname> row for every column in every
table in the database. (There will also be attribute entries for
2020-09-03 13:15:53 +02:00
indexes, and indeed all objects that have
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>
2005-01-06 00:42:03 +01:00
entries.)
2000-11-29 21:15:59 +01:00
</para>
<para>
The term attribute is equivalent to column and is used for
historical reasons.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_attribute</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table this column belongs to
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attname</structfield> <type>name</type>
</para>
<para>
The column name
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>atttypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
The data type of this column (zero for a dropped column)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attlen</structfield> <type>int2</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
A copy of <literal>pg_type.typlen</literal> of this column's
type
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attnum</structfield> <type>int2</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
The number of the column. Ordinary columns are numbered from 1
2019-04-18 02:22:56 +02:00
up. System columns, such as <structfield>ctid</structfield>,
2010-08-17 06:37:21 +02:00
have (arbitrary) negative numbers.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attcacheoff</structfield> <type>int4</type>
</para>
<para>
2003-11-01 02:56:29 +01:00
Always -1 in storage, but when loaded into a row descriptor
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
in memory this might be updated to cache the offset of the attribute
2006-11-12 07:25:37 +01:00
within the row
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>atttypmod</structfield> <type>int4</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
<structfield>atttypmod</structfield> records type-specific data
supplied at table creation time (for example, the maximum
length of a <type>varchar</type> column). It is passed to
2002-09-24 23:26:44 +02:00
type-specific input functions and length coercion functions.
2017-10-09 03:44:17 +02:00
The value will generally be -1 for types that do not need <structfield>atttypmod</structfield>.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2023-03-28 09:58:14 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attndims</structfield> <type>int2</type>
</para>
<para>
Number of dimensions, if the column is an array type; otherwise 0.
(Presently, the number of dimensions of an array is not enforced,
so any nonzero value effectively means <quote>it's an array</quote>.)
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attbyval</structfield> <type>bool</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
A copy of <literal>pg_type.typbyval</literal> of this column's type
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2021-05-23 18:12:09 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attalign</structfield> <type>char</type>
</para>
<para>
A copy of <literal>pg_type.typalign</literal> of this column's type
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attstorage</structfield> <type>char</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Normally a copy of <literal>pg_type.typstorage</literal> of this
2003-04-15 15:23:35 +02:00
column's type. For TOAST-able data types, this can be altered
2010-08-17 06:37:21 +02:00
after column creation to control storage policy.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2021-05-23 18:12:09 +02:00
<structfield>attcompression</structfield> <type>char</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
2021-05-27 19:24:24 +02:00
The current compression method of the column. Typically this is
<literal>'\0'</literal> to specify use of the current default setting
(see <xref linkend="guc-default-toast-compression"/>). Otherwise,
<literal>'p'</literal> selects pglz compression, while
<literal>'l'</literal> selects <productname>LZ4</productname>
compression. However, this field is ignored
whenever <structfield>attstorage</structfield> does not allow
compression.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attnotnull</structfield> <type>bool</type>
</para>
<para>
Catalog not-null constraints
We now create contype='n' pg_constraint rows for not-null constraints.
We propagate these constraints to other tables during operations such as
adding inheritance relationships, creating and attaching partitions and
creating tables LIKE other tables. We also spawn not-null constraints
for inheritance child tables when their parents have primary keys.
These related constraints mostly follow the well-known rules of
conislocal and coninhcount that we have for CHECK constraints, with some
adaptations: for example, as opposed to CHECK constraints, we don't
match not-null ones by name when descending a hierarchy to alter it,
instead matching by column name that they apply to. This means we don't
require the constraint names to be identical across a hierarchy.
For now, we omit them for system catalogs. Maybe this is worth
reconsidering. We don't support NOT VALID nor DEFERRABLE clauses
either; these can be added as separate features later (this patch is
already large and complicated enough.)
psql shows these constraints in \d+.
pg_dump requires some ad-hoc hacks, particularly when dumping a primary
key. We now create one "throwaway" not-null constraint for each column
in the PK together with the CREATE TABLE command, and once the PK is
created, all those throwaway constraints are removed. This avoids
having to check each tuple for nullness when the dump restores the
primary key creation.
pg_upgrading from an older release requires a somewhat brittle procedure
to create a constraint state that matches what would be created if the
database were being created fresh in Postgres 17. I have tested all the
scenarios I could think of, and it works correctly as far as I can tell,
but I could have neglected weird cases.
This patch has been very long in the making. The first patch was
written by Bernd Helmle in 2010 to add a new pg_constraint.contype value
('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one
was killed by the realization that we ought to use contype='c' instead:
manufactured CHECK constraints. However, later SQL standard
development, as well as nonobvious emergent properties of that design
(mostly, failure to distinguish them from "normal" CHECK constraints as
well as the performance implication of having to test the CHECK
expression) led us to reconsider this choice, so now the current
implementation uses contype='n' again. During Postgres 16 this had
already been introduced by commit e056c557aef4, but there were some
problems mainly with the pg_upgrade procedure that couldn't be fixed in
reasonable time, so it was reverted.
In 2016 Vitaly Burovoy also worked on this feature[1] but found no
consensus for his proposed approach, which was claimed to be closer to
the letter of the standard, requiring an additional pg_attribute column
to track the OID of the not-null constraint for that column.
[1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Author: Bernd Helmle <mailings@oopsware.de>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
This column is marked not-null, either by a not-null constraint
or a primary key.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>atthasdef</structfield> <type>bool</type>
</para>
<para>
2019-03-30 08:13:09 +01:00
This column has a default expression or generation expression, in which
case there will be a corresponding entry in the
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-attrdef"><structname>pg_attrdef</structname></link> catalog that actually defines the
2019-03-30 08:13:09 +01:00
expression. (Check <structfield>attgenerated</structfield> to
determine whether this is a default or a generation expression.)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2018-03-28 02:13:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>atthasmissing</structfield> <type>bool</type>
</para>
<para>
2018-03-28 02:13:52 +02:00
This column has a value which is used where the column is entirely
missing from the row, as happens when a column is added with a
non-volatile <literal>DEFAULT</literal> value after the row is created.
The actual value used is stored in the
<structfield>attmissingval</structfield> column.
2020-05-14 05:03:39 +02:00
</para></entry>
2018-03-28 02:13:52 +02:00
</row>
2017-04-06 14:33:16 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attidentity</structfield> <type>char</type>
</para>
<para>
2017-04-06 14:33:16 +02:00
If a zero byte (<literal>''</literal>), then not an identity column.
Otherwise, <literal>a</literal> = generated
always, <literal>d</literal> = generated by default.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-04-06 14:33:16 +02:00
</row>
2019-03-30 08:13:09 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attgenerated</structfield> <type>char</type>
</para>
<para>
2019-03-30 08:13:09 +01:00
If a zero byte (<literal>''</literal>), then not a generated column.
Otherwise, <literal>s</literal> = stored. (Other values might be added
in the future.)
2020-05-14 05:03:39 +02:00
</para></entry>
2019-03-30 08:13:09 +01:00
</row>
2002-08-02 20:15:10 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attisdropped</structfield> <type>bool</type>
</para>
<para>
2002-08-02 20:15:10 +02:00
This column has been dropped and is no longer valid. A dropped
column is still physically present in the table, but is
2010-08-17 06:37:21 +02:00
ignored by the parser and so cannot be accessed via SQL.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-08-02 20:15:10 +02:00
</row>
2002-08-30 21:23:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attislocal</structfield> <type>bool</type>
</para>
<para>
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
This column is defined locally in the relation. Note that a column can
2010-08-17 06:37:21 +02:00
be locally defined and inherited simultaneously.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-09-22 21:42:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2023-03-28 09:58:14 +02:00
<structfield>attinhcount</structfield> <type>int2</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
The number of direct ancestors this column has. A column with a
2010-08-17 06:37:21 +02:00
nonzero number of ancestors cannot be dropped nor renamed.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-08-30 21:23:20 +02:00
</row>
2024-01-14 07:46:01 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attcollation</structfield> <type>oid</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The defined collation of the column, or zero if the column is
not of a collatable data type
</para></entry>
</row>
2023-03-28 09:58:14 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attstattarget</structfield> <type>int2</type>
</para>
<para>
<structfield>attstattarget</structfield> controls the level of detail
of statistics accumulated for this column by
<link linkend="sql-analyze"><command>ANALYZE</command></link>.
A zero value indicates that no statistics should be collected.
2024-01-14 07:46:01 +01:00
A null value says to use the system default statistics target.
2023-03-28 09:58:14 +02:00
The exact meaning of positive values is data type-dependent.
For scalar data types, <structfield>attstattarget</structfield>
is both the target number of <quote>most common values</quote>
to collect, and the target number of histogram bins to create.
</para></entry>
</row>
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2020-05-14 05:03:39 +02:00
<structfield>attacl</structfield> <type>aclitem[]</type>
</para>
<para>
2009-01-22 21:16:10 +01:00
Column-level access privileges, if any have been granted specifically
on this column
2020-05-14 05:03:39 +02:00
</para></entry>
2009-01-22 21:16:10 +01:00
</row>
2010-01-22 17:40:19 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attoptions</structfield> <type>text[]</type>
</para>
<para>
Attribute-level options, as <quote>keyword=value</quote> strings
</para></entry>
2010-01-22 17:40:19 +01:00
</row>
2011-08-05 19:24:03 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attfdwoptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Attribute-level foreign data wrapper options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2011-08-05 19:24:03 +02:00
</row>
2018-03-28 02:13:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attmissingval</structfield> <type>anyarray</type>
</para>
<para>
2018-03-28 02:13:52 +02:00
This column has a one element array containing the value used when the
column is entirely missing from the row, as happens when the column is
added with a non-volatile <literal>DEFAULT</literal> value after the
row is created. The value is only used when
<structfield>atthasmissing</structfield> is true. If there is no value
the column is null.
2020-05-14 05:03:39 +02:00
</para></entry>
2018-03-28 02:13:52 +02:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
2005-01-06 00:42:03 +01:00
<para>
In a dropped column's <structname>pg_attribute</structname> entry,
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
<structfield>atttypid</structfield> is reset to zero, but
2005-01-06 00:42:03 +01:00
<structfield>attlen</structfield> and the other fields copied from
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-type"><structname>pg_type</structname></link> are still valid. This arrangement is needed
2005-01-06 00:42:03 +01:00
to cope with the situation where the dropped column's data type was
2017-10-09 03:44:17 +02:00
later dropped, and so there is no <structname>pg_type</structname> row anymore.
2005-01-06 00:42:03 +01:00
<structfield>attlen</structfield> and the other fields can be used
to interpret the contents of a row of the table.
</para>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2005-06-28 07:09:14 +02:00
<sect1 id="catalog-pg-authid">
<title><structname>pg_authid</structname></title>
<indexterm zone="catalog-pg-authid">
<primary>pg_authid</primary>
</indexterm>
<para>
The catalog <structname>pg_authid</structname> contains information about
database authorization identifiers (roles). A role subsumes the concepts
2017-10-09 03:44:17 +02:00
of <quote>users</quote> and <quote>groups</quote>. A user is essentially just a
role with the <structfield>rolcanlogin</structfield> flag set. Any role (with or
without <structfield>rolcanlogin</structfield>) can have other roles as members; see
2005-06-28 07:09:14 +02:00
<link linkend="catalog-pg-auth-members"><structname>pg_auth_members</structname></link>.
</para>
<para>
Since this catalog contains passwords, it must not be publicly readable.
<link linkend="view-pg-roles"><structname>pg_roles</structname></link>
is a publicly readable view on
<structname>pg_authid</structname> that blanks out the password field.
</para>
<para>
2017-11-23 15:39:47 +01:00
<xref linkend="user-manag"/> contains detailed information about user and
2005-06-28 07:09:14 +02:00
privilege management.
</para>
<para>
Because user identities are cluster-wide,
<structname>pg_authid</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_authid</structname> per cluster, not
one per database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_authid</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2005-06-28 07:09:14 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2005-06-28 07:09:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolname</structfield> <type>name</type>
</para>
<para>
Role name
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolsuper</structfield> <type>bool</type>
</para>
<para>
Role has superuser privileges
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
2005-07-26 18:38:29 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolinherit</structfield> <type>bool</type>
</para>
<para>
Role automatically inherits privileges of roles it is a
member of
</para></entry>
2005-07-26 18:38:29 +02:00
</row>
2005-06-28 07:09:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolcreaterole</structfield> <type>bool</type>
</para>
<para>
Role can create more roles
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolcreatedb</structfield> <type>bool</type>
</para>
<para>
Role can create databases
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolcanlogin</structfield> <type>bool</type>
</para>
<para>
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Role can log in. That is, this role can be given as the initial
2020-10-19 18:28:54 +02:00
session authorization identifier.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
2010-12-29 11:05:03 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolreplication</structfield> <type>bool</type>
</para>
<para>
2017-08-11 22:14:55 +02:00
Role is a replication role. A replication role can initiate replication
connections and create and drop replication slots.
2020-05-14 05:03:39 +02:00
</para></entry>
2010-12-29 11:05:03 +01:00
</row>
2015-01-29 03:47:15 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolbypassrls</structfield> <type>bool</type>
</para>
<para>
2021-04-21 08:14:43 +02:00
Role bypasses every row-level security policy, see
2017-11-23 15:39:47 +01:00
<xref linkend="ddl-rowsecurity"/> for more information.
2020-05-14 05:03:39 +02:00
</para></entry>
2015-01-29 03:47:15 +01:00
</row>
2005-07-31 19:19:22 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolconnlimit</structfield> <type>int4</type>
</para>
<para>
2014-12-23 19:35:49 +01:00
For roles that can log in, this sets maximum number of concurrent
connections this role can make. -1 means no limit.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-07-31 19:19:22 +02:00
</row>
2014-12-23 19:35:49 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolpassword</structfield> <type>text</type>
</para>
<para>
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
Password (possibly encrypted); null if none. The format depends
on the form of encryption used.
2020-05-14 05:03:39 +02:00
</para></entry>
2014-12-23 19:35:49 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolvaliduntil</structfield> <type>timestamptz</type>
</para>
<para>
Password expiry time (only used for password authentication);
null if no expiration
</para></entry>
2014-12-23 19:35:49 +01:00
</row>
2005-06-28 07:09:14 +02:00
</tbody>
</tgroup>
</table>
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
<para>
For an MD5 encrypted password, <structfield>rolpassword</structfield>
2017-10-09 03:44:17 +02:00
column will begin with the string <literal>md5</literal> followed by a
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
32-character hexadecimal MD5 hash. The MD5 hash will be of the user's
password concatenated to their user name. For example, if user
2017-10-09 03:44:17 +02:00
<literal>joe</literal> has password <literal>xyzzy</literal>, <productname>PostgreSQL</productname>
will store the md5 hash of <literal>xyzzyjoe</literal>.
2017-04-21 21:51:57 +02:00
</para>
<para>
If the password is encrypted with SCRAM-SHA-256, it has the format:
<synopsis>
2017-10-09 03:44:17 +02:00
SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable><salt></replaceable>$<replaceable><StoredKey></replaceable>:<replaceable><ServerKey></replaceable>
2017-04-21 21:51:57 +02:00
</synopsis>
2017-10-09 03:44:17 +02:00
where <replaceable>salt</replaceable>, <replaceable>StoredKey</replaceable> and
<replaceable>ServerKey</replaceable> are in Base64 encoded format. This format is
2020-12-01 13:36:30 +01:00
the same as that specified by <ulink url="https://tools.ietf.org/html/rfc5803">RFC 5803</ulink>.
2017-04-21 21:51:57 +02:00
</para>
<para>
A password that does not follow either of those formats is assumed to be
unencrypted.
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
This introduces a new generic SASL authentication method, similar to the
GSS and SSPI methods. The server first tells the client which SASL
authentication mechanism to use, and then the mechanism-specific SASL
messages are exchanged in AuthenticationSASLcontinue and PasswordMessage
messages. Only SCRAM-SHA-256 is supported at the moment, but this allows
adding more SASL mechanisms in the future, without changing the overall
protocol.
Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later.
The SASLPrep algorithm, for pre-processing the password, is not yet
implemented. That could cause trouble, if you use a password with
non-ASCII characters, and a client library that does implement SASLprep.
That will hopefully be added later.
Authorization identities, as specified in the SCRAM-SHA-256 specification,
are ignored. SET SESSION AUTHORIZATION provides more or less the same
functionality, anyway.
If a user doesn't exist, perform a "mock" authentication, by constructing
an authentic-looking challenge on the fly. The challenge is derived from
a new system-wide random value, "mock authentication nonce", which is
created at initdb, and stored in the control file. We go through these
motions, in order to not give away the information on whether the user
exists, to unauthenticated users.
Bumps PG_CONTROL_VERSION, because of the new field in control file.
Patch by Michael Paquier and Heikki Linnakangas, reviewed at different
stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev,
and many others.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
</para>
2005-06-28 07:09:14 +02:00
</sect1>
<sect1 id="catalog-pg-auth-members">
<title><structname>pg_auth_members</structname></title>
<indexterm zone="catalog-pg-auth-members">
<primary>pg_auth_members</primary>
</indexterm>
<para>
The catalog <structname>pg_auth_members</structname> shows the membership
relations between roles. Any non-circular set of relationships is allowed.
</para>
<para>
Because user identities are cluster-wide,
<structname>pg_auth_members</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_auth_members</structname> per cluster, not
one per database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_auth_members</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2005-06-28 07:09:14 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Ensure that pg_auth_members.grantor is always valid.
Previously, "GRANT foo TO bar" or "GRANT foo TO bar GRANTED BY baz"
would record the OID of the grantor in pg_auth_members.grantor, but
that role could later be dropped without modifying or removing the
pg_auth_members record. That's not great, because we typically try
to avoid dangling references in catalog data.
Now, a role grant depends on the grantor, and the grantor can't be
dropped without removing the grant or changing the grantor. "DROP
OWNED BY" will remove the grant, just as it does for other kinds of
privileges. "REASSIGN OWNED BY" will not, again just like what we do
in other cases involving privileges.
pg_auth_members now has an OID column, because that is needed in order
for dependencies to work. It also now has an index on the grantor
column, because otherwise dropping a role would require a sequential
scan of the entire table to see whether the role's OID is in use as
a grantor. That probably wouldn't be too large a problem in practice,
but it seems better to have an index just in case.
A follow-on patch is planned with the goal of more thoroughly
rationalizing the behavior of role grants. This patch is just trying
to do enough to make sure that the data we store in the catalogs is at
some basic level valid.
Patch by me, reviewed by Stephen Frost
Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
2022-08-18 19:13:02 +02:00
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2020-05-14 05:03:39 +02:00
<structfield>roleid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of a role that has a member
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>member</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of a role that is a member of <structfield>roleid</structfield>
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>grantor</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of the role that granted this membership
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>admin_option</structfield> <type>bool</type>
</para>
<para>
True if <structfield>member</structfield> can grant membership in
<structfield>roleid</structfield> to others
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
2022-08-25 16:06:02 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inherit_option</structfield> <type>bool</type>
</para>
<para>
True if the member automatically inherits the privileges of the
granted role
</para></entry>
</row>
Add a SET option to the GRANT command.
Similar to how the INHERIT option controls whether or not the
permissions of the granted role are automatically available to the
grantee, the new SET permission controls whether or not the grantee
may use the SET ROLE command to assume the privileges of the granted
role.
In addition, the new SET permission controls whether or not it
is possible to transfer ownership of objects to the target role
or to create new objects owned by the target role using commands
such as CREATE DATABASE .. OWNER. We could alternatively have made
this controlled by the INHERIT option, or allow it when either
option is given. An advantage of this approach is that if you
are granted a predefined role with INHERIT TRUE, SET FALSE, you
can't go and create objects owned by that role.
The underlying theory here is that the ability to create objects
as a target role is not a privilege per se, and thus does not
depend on whether you inherit the target role's privileges. However,
it's surely something you could do anyway if you could SET ROLE
to the target role, and thus making it contingent on whether you
have that ability is reasonable.
Design review by Nathan Bossat, Wolfgang Walther, Jeff Davis,
Peter Eisentraut, and Stephen Frost.
Discussion: http://postgr.es/m/CA+Tgmob+zDSRS6JXYrgq0NWdzCXuTNzT5eK54Dn2hhgt17nm8A@mail.gmail.com
2022-11-18 18:32:50 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>set_option</structfield> <type>bool</type>
</para>
<para>
True if the member can
<link linkend="sql-set-role"><command>SET ROLE</command></link>
to the granted role
</para></entry>
</row>
2005-06-28 07:09:14 +02:00
</tbody>
</tgroup>
</table>
</sect1>
2002-07-22 22:23:19 +02:00
<sect1 id="catalog-pg-cast">
2003-04-15 15:23:35 +02:00
<title><structname>pg_cast</structname></title>
<indexterm zone="catalog-pg-cast">
<primary>pg_cast</primary>
</indexterm>
2002-07-22 22:23:19 +02:00
<para>
2007-06-05 23:31:09 +02:00
The catalog <structname>pg_cast</structname> stores data type conversion
2012-05-11 00:02:37 +02:00
paths, both built-in and user-defined.
2002-07-22 22:23:19 +02:00
</para>
2007-06-05 23:31:09 +02:00
<para>
It should be noted that <structname>pg_cast</structname> does not represent
every type conversion that the system knows how to perform; only those that
cannot be deduced from some generic rule. For example, casting between a
domain and its base type is not explicitly represented in
<structname>pg_cast</structname>. Another important exception is that
2017-10-09 03:44:17 +02:00
<quote>automatic I/O conversion casts</quote>, those performed using a data
type's own I/O functions to convert to or from <type>text</type> or other
2008-10-31 09:39:22 +01:00
string types, are not explicitly represented in
<structname>pg_cast</structname>.
2007-06-05 23:31:09 +02:00
</para>
2002-07-22 22:23:19 +02:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_cast</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-22 22:23:19 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-22 22:23:19 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-22 22:23:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>castsource</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the source data type
</para></entry>
2002-07-22 22:23:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>casttarget</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the target data type
</para></entry>
2002-07-22 22:23:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>castfunc</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
The OID of the function to use to perform this cast. Zero is
2008-10-31 09:39:22 +01:00
stored if the cast method doesn't require a function.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-22 22:23:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>castcontext</structfield> <type>char</type>
</para>
<para>
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Indicates what contexts the cast can be invoked in.
2017-10-09 03:44:17 +02:00
<literal>e</literal> means only as an explicit cast (using
<literal>CAST</literal> or <literal>::</literal> syntax).
<literal>a</literal> means implicitly in assignment
Extend pg_cast castimplicit column to a three-way value; this allows us
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
2002-09-18 23:35:25 +02:00
to a target column, as well as explicitly.
2017-10-09 03:44:17 +02:00
<literal>i</literal> means implicitly in expressions, as well as the
2010-08-17 06:37:21 +02:00
other cases.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-22 22:23:19 +02:00
</row>
2020-05-14 05:03:39 +02:00
2008-10-31 09:39:22 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>castmethod</structfield> <type>char</type>
</para>
<para>
2008-10-31 09:39:22 +01:00
Indicates how the cast is performed.
2017-10-09 03:44:17 +02:00
<literal>f</literal> means that the function specified in the <structfield>castfunc</structfield> field is used.
<literal>i</literal> means that the input/output functions are used.
<literal>b</literal> means that the types are binary-coercible, thus no conversion is required.
2020-05-14 05:03:39 +02:00
</para></entry>
2008-10-31 09:39:22 +01:00
</row>
2002-07-22 22:23:19 +02:00
</tbody>
</tgroup>
</table>
2004-06-16 03:27:00 +02:00
<para>
The cast functions listed in <structname>pg_cast</structname> must
always take the cast source type as their first argument type, and
return the cast destination type as their result type. A cast
function can have up to three arguments. The second argument,
2017-10-09 03:44:17 +02:00
if present, must be type <type>integer</type>; it receives the type
2011-02-07 00:32:27 +01:00
modifier associated with the destination type, or -1
2004-06-16 03:27:00 +02:00
if there is none. The third argument,
2017-10-09 03:44:17 +02:00
if present, must be type <type>boolean</type>; it receives <literal>true</literal>
if the cast is an explicit cast, <literal>false</literal> otherwise.
2004-06-16 03:27:00 +02:00
</para>
<para>
It is legitimate to create a <structname>pg_cast</structname> entry
in which the source and target types are the same, if the associated
function takes more than one argument. Such entries represent
2017-10-09 03:44:17 +02:00
<quote>length coercion functions</quote> that coerce values of the type
2007-04-02 05:49:42 +02:00
to be legal for a particular type modifier value.
2004-06-16 03:27:00 +02:00
</para>
<para>
When a <structname>pg_cast</structname> entry has different source and
target types and a function that takes more than one argument, it
represents converting from one type to another and applying a length
coercion in a single step. When no such entry is available, coercion
to a type that uses a type modifier involves two steps, one to
2004-12-13 19:05:10 +01:00
convert between data types and a second to apply the modifier.
2004-06-16 03:27:00 +02:00
</para>
2002-07-22 22:23:19 +02:00
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-class">
2003-04-15 15:23:35 +02:00
<title><structname>pg_class</structname></title>
<indexterm zone="catalog-pg-class">
<primary>pg_class</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2023-09-22 20:52:36 +02:00
The catalog <structname>pg_class</structname> describes tables and
other objects that have columns or are otherwise similar to a
2020-09-03 13:15:53 +02:00
table. This includes indexes (but see also <link
linkend="catalog-pg-index"><structname>pg_index</structname></link>),
sequences (but see also <link
linkend="catalog-pg-sequence"><structname>pg_sequence</structname></link>),
views, materialized views, composite types, and TOAST tables;
see <structfield>relkind</structfield>.
Below, when we mean all of these kinds of objects we speak of
2023-09-22 20:52:36 +02:00
<quote>relations</quote>. Not all of <structname>pg_class</structname>'s
columns are meaningful for all relation kinds.
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_class</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relname</structfield> <type>name</type>
</para>
<para>
Name of the table, index, view, etc.
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2002-03-26 20:17:02 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-03-26 20:17:02 +01:00
The OID of the namespace that contains this relation
2020-05-14 05:03:39 +02:00
</para></entry>
2002-03-26 20:17:02 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reltype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2004-12-13 19:05:10 +01:00
The OID of the data type that corresponds to this table's row type,
2021-02-02 22:15:29 +01:00
if any; zero for indexes, sequences, and toast tables, which have
no <structname>pg_type</structname> entry
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2010-08-25 20:18:41 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reloftype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
For typed tables, the OID of the underlying composite type;
2010-08-25 20:18:41 +02:00
zero for all other relations
2020-05-14 05:03:39 +02:00
</para></entry>
2010-08-25 20:18:41 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the relation
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relam</structfield> <type>oid</type>
(references <link linkend="catalog-pg-am"><structname>pg_am</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2024-03-25 16:30:36 +01:00
The access method used to access this table or index.
Not meaningful if the relation is a sequence or
has no on-disk file,
except for partitioned tables, where, if set, it takes
precedence over <varname>default_table_access_method</varname>
when determining the access method to use for partitions created
when one is not specified in the creation command.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2022-09-28 15:45:27 +02:00
<structfield>relfilenode</structfield> <type>oid</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
Name of the on-disk file of this relation; zero means this
2017-10-09 03:44:17 +02:00
is a <quote>mapped</quote> relation whose disk file name is determined
2020-05-14 05:03:39 +02:00
by low-level state
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2004-06-18 08:14:31 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reltablespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2024-03-20 15:28:14 +01:00
The tablespace in which this relation is stored.
If zero, the database's default tablespace is implied.
Not meaningful if the relation has no on-disk file,
except for partitioned tables, where this is the tablespace
in which partitions will be created when one is not
specified in the creation command.
2020-05-14 05:03:39 +02:00
</para></entry>
2004-06-18 08:14:31 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relpages</structfield> <type>int4</type>
</para>
<para>
2004-12-01 20:00:56 +01:00
Size of the on-disk representation of this table in pages (of size
2006-11-12 07:25:37 +01:00
<symbol>BLCKSZ</symbol>). This is only an estimate used by the
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
planner. It is updated by <link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>, and a few DDL commands such as
<link linkend="sql-createindex"><command>CREATE INDEX</command></link>.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reltuples</structfield> <type>float4</type>
</para>
<para>
2018-03-22 20:47:29 +01:00
Number of live rows in the table. This is only an estimate used by
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
the planner. It is updated by <link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>, and a few DDL commands such as
<link linkend="sql-createindex"><command>CREATE INDEX</command></link>.
Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.
Historically, we've considered the state with relpages and reltuples
both zero as indicating that we do not know the table's tuple density.
This is problematic because it's impossible to distinguish "never yet
vacuumed" from "vacuumed and seen to be empty". In particular, a user
cannot use VACUUM or ANALYZE to override the planner's normal heuristic
that an empty table should not be believed to be empty because it is
probably about to get populated. That heuristic is a good safety
measure, so I don't care to abandon it, but there should be a way to
override it if the table is indeed intended to stay empty.
Hence, represent the initial state of ignorance by setting reltuples
to -1 (relpages is still set to zero), and apply the minimum-ten-pages
heuristic only when reltuples is still -1. If the table is empty,
VACUUM or ANALYZE (but not CREATE INDEX) will override that to
reltuples = relpages = 0, and then we'll plan on that basis.
This requires a bunch of fiddly little changes, but we can get rid of
some ugly kluges that were formerly needed to maintain the old definition.
One notable point is that FDWs' GetForeignRelSize methods will see
baserel->tuples = -1 when no ANALYZE has been done on the foreign table.
That seems like a net improvement, since those methods were formerly
also in the dark about what baserel->tuples = 0 really meant. Still,
it is an API change.
I bumped catversion because code predating this change would get confused
by seeing reltuples = -1.
Discussion: https://postgr.es/m/F02298E0-6EF4-49A1-BCB6-C484794D9ACC@thebuild.com
2020-08-30 18:21:51 +02:00
If the table has never yet been vacuumed or
analyzed, <structfield>reltuples</structfield>
contains <literal>-1</literal> indicating that the row count is
unknown.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2011-10-14 23:23:01 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relallvisible</structfield> <type>int4</type>
</para>
<para>
2011-10-14 23:23:01 +02:00
Number of pages that are marked all-visible in the table's
visibility map. This is only an estimate used by the
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
planner. It is updated by <link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>, and a few DDL commands such as
<link linkend="sql-createindex"><command>CREATE INDEX</command></link>.
2020-05-14 05:03:39 +02:00
</para></entry>
2011-10-14 23:23:01 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reltoastrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
OID of the TOAST table associated with this table, zero if none. The
2006-11-12 07:25:37 +01:00
TOAST table stores large attributes <quote>out of line</quote> in a
2010-08-17 06:37:21 +02:00
secondary table.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relhasindex</structfield> <type>bool</type>
</para>
<para>
2009-12-07 06:22:23 +01:00
True if this is a table and it has (or recently had) any indexes
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relisshared</structfield> <type>bool</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
True if this table is shared across all databases in the cluster. Only
2020-09-03 13:15:53 +02:00
certain system catalogs (such as <link linkend="catalog-pg-database"><structname>pg_database</structname></link>)
2010-08-17 06:37:21 +02:00
are shared.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2009-03-31 19:59:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relpersistence</structfield> <type>char</type>
</para>
<para>
2022-04-11 10:50:20 +02:00
<literal>p</literal> = permanent table/sequence, <literal>u</literal> = unlogged table/sequence,
<literal>t</literal> = temporary table/sequence
2020-05-14 05:03:39 +02:00
</para></entry>
2009-03-31 19:59:56 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relkind</structfield> <type>char</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
<literal>r</literal> = ordinary table,
<literal>i</literal> = index,
<literal>S</literal> = sequence,
<literal>t</literal> = TOAST table,
<literal>v</literal> = view,
<literal>m</literal> = materialized view,
<literal>c</literal> = composite type,
<literal>f</literal> = foreign table,
2018-05-09 18:32:50 +02:00
<literal>p</literal> = partitioned table,
<literal>I</literal> = partitioned index
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relnatts</structfield> <type>int2</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
Number of user columns in the relation (system columns not
counted). There must be this many corresponding entries in
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>. See also
<structname>pg_attribute</structname>.<structfield>attnum</structfield>.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relchecks</structfield> <type>int2</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Number of <literal>CHECK</literal> constraints on the table; see
2006-11-12 07:25:37 +01:00
<link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> catalog
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relhasrules</structfield> <type>bool</type>
</para>
<para>
2008-11-09 22:24:33 +01:00
True if table has (or once had) rules; see
2006-11-12 07:25:37 +01:00
<link linkend="catalog-pg-rewrite"><structname>pg_rewrite</structname></link> catalog
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2008-11-09 22:24:33 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relhastriggers</structfield> <type>bool</type>
</para>
<para>
2008-11-09 22:24:33 +01:00
True if table has (or once had) triggers; see
<link linkend="catalog-pg-trigger"><structname>pg_trigger</structname></link> catalog
2020-05-14 05:03:39 +02:00
</para></entry>
2008-11-09 22:24:33 +01:00
</row>
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
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relhassubclass</structfield> <type>bool</type>
</para>
<para>
2022-07-28 18:21:56 +02:00
True if table or index has (or once had) any inheritance children or partitions
2020-05-14 05:03:39 +02:00
</para></entry>
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
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relrowsecurity</structfield> <type>bool</type>
</para>
<para>
2021-04-21 08:14:43 +02:00
True if table has row-level security enabled; see
2015-01-24 22:16:22 +01:00
<link linkend="catalog-pg-policy"><structname>pg_policy</structname></link> catalog
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2015-10-05 03:05:08 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relforcerowsecurity</structfield> <type>bool</type>
</para>
<para>
2021-04-21 08:14:43 +02:00
True if row-level security (when enabled) will also apply to table owner; see
2015-10-05 03:05:08 +02:00
<link linkend="catalog-pg-policy"><structname>pg_policy</structname></link> catalog
2020-05-14 05:03:39 +02:00
</para></entry>
2015-10-05 03:05:08 +02:00
</row>
2013-05-06 19:26:51 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relispopulated</structfield> <type>bool</type>
</para>
<para>
True if relation is populated (this is true for all
relations other than some materialized views)
</para></entry>
2013-05-06 19:26:51 +02:00
</row>
2013-11-08 18:30:43 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relreplident</structfield> <type>char</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Columns used to form <quote>replica identity</quote> for rows:
<literal>d</literal> = default (primary key, if any),
<literal>n</literal> = nothing,
2020-05-20 07:20:50 +02:00
<literal>f</literal> = all columns,
<literal>i</literal> = index with
<structfield>indisreplident</structfield> set (same as nothing if the
index used has been dropped)
2020-05-14 05:03:39 +02:00
</para></entry>
2013-11-08 18:30:43 +01:00
</row>
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relispartition</structfield> <type>bool</type>
</para>
<para>
True if table or index is a partition
</para></entry>
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</row>
2018-03-21 14:13:24 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relrewrite</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2018-03-21 14:13:24 +01:00
For new relations being written during a DDL operation that requires a
table rewrite, this contains the OID of the original relation;
2021-02-02 22:15:29 +01:00
otherwise zero. That state is only visible internally; this field should
never contain anything other than zero for a user-visible relation.
2020-05-14 05:03:39 +02:00
</para></entry>
2018-03-21 14:13:24 +01:00
</row>
2006-07-10 18:20:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relfrozenxid</structfield> <type>xid</type>
</para>
<para>
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
All transaction IDs before this one have been replaced with a permanent
2017-10-09 03:44:17 +02:00
(<quote>frozen</quote>) transaction ID in this table. This is used to track
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
whether the table needs to be vacuumed in order to prevent transaction
2017-10-09 03:44:17 +02:00
ID wraparound or to allow <literal>pg_xact</literal> to be shrunk. Zero
2010-08-17 06:37:21 +02:00
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.
2020-05-14 05:03:39 +02:00
</para></entry>
2006-07-10 18:20:52 +02:00
</row>
2013-06-27 21:20:33 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relminmxid</structfield> <type>xid</type>
</para>
<para>
2015-06-04 06:22:49 +02:00
All multixact IDs before this one have been replaced by a
2013-06-27 21:20:33 +02:00
transaction ID in this table. This is used to track
2015-06-04 06:22:49 +02:00
whether the table needs to be vacuumed in order to prevent multixact ID
2017-10-09 03:44:17 +02:00
wraparound or to allow <literal>pg_multixact</literal> to be shrunk. Zero
2015-06-04 06:22:49 +02:00
(<symbol>InvalidMultiXactId</symbol>) if the relation is not a table.
2020-05-14 05:03:39 +02:00
</para></entry>
2013-06-27 21:20:33 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2006-07-04 00:45:41 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reloptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Access-method-specific options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2006-07-04 00:45:41 +02:00
</row>
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relpartbound</structfield> <type>pg_node_tree</type>
</para>
<para>
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
If table is a partition (see <structfield>relispartition</structfield>),
internal representation of the partition bound
2020-05-14 05:03:39 +02:00
</para></entry>
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
2009-12-07 06:22:23 +01:00
<para>
2017-10-09 03:44:17 +02:00
Several of the Boolean flags in <structname>pg_class</structname> are maintained
2009-12-07 06:22:23 +01:00
lazily: they are guaranteed to be true if that's the correct state, but
may not be reset to false immediately when the condition is no longer
2017-10-09 03:44:17 +02:00
true. For example, <structfield>relhasindex</structfield> is set by
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-createindex"><command>CREATE INDEX</command></link>, but it is never cleared by
<link linkend="sql-dropindex"><command>DROP INDEX</command></link>. Instead, <link linkend="sql-vacuum"><command>VACUUM</command></link> clears
2017-10-09 03:44:17 +02:00
<structfield>relhasindex</structfield> if it finds the table has no indexes. This
2009-12-07 06:22:23 +01:00
arrangement avoids race conditions and improves concurrency.
</para>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2013-12-30 19:27:51 +01:00
<sect1 id="catalog-pg-collation">
<title><structname>pg_collation</structname></title>
2012-07-18 16:16:16 +02:00
2013-12-30 19:27:51 +01:00
<indexterm zone="catalog-pg-collation">
<primary>pg_collation</primary>
2012-07-18 16:16:16 +02:00
</indexterm>
<para>
2013-12-30 19:27:51 +01:00
The catalog <structname>pg_collation</structname> describes the
available collations, which are essentially mappings from an SQL
name to operating system locale categories.
2017-11-23 15:39:47 +01:00
See <xref linkend="collation"/> for more information.
2012-07-18 16:16:16 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_collation</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2012-07-18 16:16:16 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collname</structfield> <type>name</type>
</para>
<para>
Collation name (unique per namespace and encoding)
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2013-12-30 19:27:51 +01:00
The OID of the namespace that contains this collation
2020-05-14 05:03:39 +02:00
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the collation
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
2017-03-23 20:25:34 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collprovider</structfield> <type>char</type>
</para>
<para>
Provider of the collation: <literal>d</literal> = database
default, <literal>c</literal> = libc, <literal>i</literal> = icu
</para></entry>
2017-03-23 20:25:34 +01:00
</row>
2019-03-22 12:09:32 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collisdeterministic</structfield> <type>bool</type>
</para>
<para>
Is the collation deterministic?
</para></entry>
2019-03-22 12:09:32 +01:00
</row>
2012-07-18 16:16:16 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collencoding</structfield> <type>int4</type>
</para>
<para>
Encoding in which the collation is applicable, or -1 if it
works for any encoding
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2022-01-27 08:44:31 +01:00
<structfield>collcollate</structfield> <type>text</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
2024-03-09 23:48:18 +01:00
<symbol>LC_COLLATE</symbol> for this collation object. If the provider is
not <literal>libc</literal>, <structfield>collcollate</structfield> is
<literal>NULL</literal> and <structfield>colllocale</structfield> is
used instead.
2020-05-14 05:03:39 +02:00
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2022-01-27 08:44:31 +01:00
<structfield>collctype</structfield> <type>text</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
2024-03-09 23:48:18 +01:00
<symbol>LC_CTYPE</symbol> for this collation object. If the provider is
not <literal>libc</literal>, <structfield>collctype</structfield> is
<literal>NULL</literal> and <structfield>colllocale</structfield> is
used instead.
2020-05-14 05:03:39 +02:00
</para></entry>
2012-07-18 16:16:16 +02:00
</row>
2021-05-07 10:17:42 +02:00
2022-03-17 11:11:21 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2024-03-09 23:48:18 +01:00
<structfield>colllocale</structfield> <type>text</type>
2022-03-17 11:11:21 +01:00
</para>
<para>
2024-03-09 23:48:18 +01:00
Collation provider locale name for this collation object. If the
provider is <literal>libc</literal>,
<structfield>colllocale</structfield> is <literal>NULL</literal>;
<structfield>collcollate</structfield> and
<structfield>collctype</structfield> are used instead.
2022-03-17 11:11:21 +01:00
</para></entry>
</row>
2023-03-08 16:35:42 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collicurules</structfield> <type>text</type>
</para>
<para>
ICU collation rules for this collation object
</para></entry>
</row>
2021-05-07 10:17:42 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collversion</structfield> <type>text</type>
</para>
<para>
Provider-specific version of the collation. This is recorded when the
collation is created and then checked when it is used, to detect
changes in the collation definition that could lead to data corruption.
</para></entry>
</row>
2012-07-18 16:16:16 +02:00
</tbody>
</tgroup>
</table>
2013-12-30 19:27:51 +01:00
<para>
2017-10-09 03:44:17 +02:00
Note that the unique key on this catalog is (<structfield>collname</structfield>,
<structfield>collencoding</structfield>, <structfield>collnamespace</structfield>) not just
(<structfield>collname</structfield>, <structfield>collnamespace</structfield>).
2013-12-30 19:27:51 +01:00
<productname>PostgreSQL</productname> generally ignores all
2017-10-09 03:44:17 +02:00
collations that do not have <structfield>collencoding</structfield> equal to
2013-12-30 19:27:51 +01:00
either the current database's encoding or -1, and creation of new entries
2017-10-09 03:44:17 +02:00
with the same name as an entry with <structfield>collencoding</structfield> = -1
2013-12-30 19:27:51 +01:00
is forbidden. Therefore it is sufficient to use a qualified SQL name
2017-10-09 03:44:17 +02:00
(<replaceable>schema</replaceable>.<replaceable>name</replaceable>) to identify a collation,
2013-12-30 19:27:51 +01:00
even though this is not unique according to the catalog definition.
The reason for defining the catalog this way is that
2017-10-09 03:44:17 +02:00
<application>initdb</application> fills it in at cluster initialization time with
2013-12-30 19:27:51 +01:00
entries for all locales available on the system, so it must be able to
hold entries for all encodings that might ever be used in the cluster.
</para>
<para>
2017-10-09 03:44:17 +02:00
In the <literal>template0</literal> database, it could be useful to create
2013-12-30 19:27:51 +01:00
collations whose encoding does not match the database encoding,
since they could match the encodings of databases later cloned from
2017-10-09 03:44:17 +02:00
<literal>template0</literal>. This would currently have to be done manually.
2013-12-30 19:27:51 +01:00
</para>
2012-07-18 16:16:16 +02:00
</sect1>
2002-07-12 20:43:19 +02:00
<sect1 id="catalog-pg-constraint">
2003-04-15 15:23:35 +02:00
<title><structname>pg_constraint</structname></title>
<indexterm zone="catalog-pg-constraint">
<primary>pg_constraint</primary>
</indexterm>
2002-07-12 20:43:19 +02:00
<para>
Catalog not-null constraints
We now create contype='n' pg_constraint rows for not-null constraints.
We propagate these constraints to other tables during operations such as
adding inheritance relationships, creating and attaching partitions and
creating tables LIKE other tables. We also spawn not-null constraints
for inheritance child tables when their parents have primary keys.
These related constraints mostly follow the well-known rules of
conislocal and coninhcount that we have for CHECK constraints, with some
adaptations: for example, as opposed to CHECK constraints, we don't
match not-null ones by name when descending a hierarchy to alter it,
instead matching by column name that they apply to. This means we don't
require the constraint names to be identical across a hierarchy.
For now, we omit them for system catalogs. Maybe this is worth
reconsidering. We don't support NOT VALID nor DEFERRABLE clauses
either; these can be added as separate features later (this patch is
already large and complicated enough.)
psql shows these constraints in \d+.
pg_dump requires some ad-hoc hacks, particularly when dumping a primary
key. We now create one "throwaway" not-null constraint for each column
in the PK together with the CREATE TABLE command, and once the PK is
created, all those throwaway constraints are removed. This avoids
having to check each tuple for nullness when the dump restores the
primary key creation.
pg_upgrading from an older release requires a somewhat brittle procedure
to create a constraint state that matches what would be created if the
database were being created fresh in Postgres 17. I have tested all the
scenarios I could think of, and it works correctly as far as I can tell,
but I could have neglected weird cases.
This patch has been very long in the making. The first patch was
written by Bernd Helmle in 2010 to add a new pg_constraint.contype value
('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one
was killed by the realization that we ought to use contype='c' instead:
manufactured CHECK constraints. However, later SQL standard
development, as well as nonobvious emergent properties of that design
(mostly, failure to distinguish them from "normal" CHECK constraints as
well as the performance implication of having to test the CHECK
expression) led us to reconsider this choice, so now the current
implementation uses contype='n' again. During Postgres 16 this had
already been introduced by commit e056c557aef4, but there were some
problems mainly with the pg_upgrade procedure that couldn't be fixed in
reasonable time, so it was reverted.
In 2016 Vitaly Burovoy also worked on this feature[1] but found no
consensus for his proposed approach, which was claimed to be closer to
the letter of the standard, requiring an additional pg_attribute column
to track the OID of the not-null constraint for that column.
[1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Author: Bernd Helmle <mailings@oopsware.de>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
The catalog <structname>pg_constraint</structname> stores check, not-null,
primary key, unique, foreign key, and exclusion constraints on tables.
2009-12-07 06:22:23 +01:00
(Column constraints are not treated specially. Every column constraint is
equivalent to some table constraint.)
2002-07-12 20:43:19 +02:00
</para>
2010-01-17 23:56:23 +01:00
<para>
2020-09-03 13:15:53 +02:00
User-defined constraint triggers (created with <link linkend="sql-createtrigger">
<command>CREATE CONSTRAINT TRIGGER</command></link>) also give rise to an entry in this table.
2010-01-17 23:56:23 +01:00
</para>
2002-07-12 20:43:19 +02:00
<para>
2003-04-15 15:23:35 +02:00
Check constraints on domains are stored here, too.
2002-07-12 20:43:19 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_constraint</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-12 20:43:19 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-12 20:43:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conname</structfield> <type>name</type>
</para>
<para>
Constraint name (not necessarily unique!)
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>connamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-07-12 20:43:19 +02:00
The OID of the namespace that contains this constraint
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>contype</structfield> <type>char</type>
</para>
<para>
<literal>c</literal> = check constraint,
<literal>f</literal> = foreign key constraint,
Catalog not-null constraints
We now create contype='n' pg_constraint rows for not-null constraints.
We propagate these constraints to other tables during operations such as
adding inheritance relationships, creating and attaching partitions and
creating tables LIKE other tables. We also spawn not-null constraints
for inheritance child tables when their parents have primary keys.
These related constraints mostly follow the well-known rules of
conislocal and coninhcount that we have for CHECK constraints, with some
adaptations: for example, as opposed to CHECK constraints, we don't
match not-null ones by name when descending a hierarchy to alter it,
instead matching by column name that they apply to. This means we don't
require the constraint names to be identical across a hierarchy.
For now, we omit them for system catalogs. Maybe this is worth
reconsidering. We don't support NOT VALID nor DEFERRABLE clauses
either; these can be added as separate features later (this patch is
already large and complicated enough.)
psql shows these constraints in \d+.
pg_dump requires some ad-hoc hacks, particularly when dumping a primary
key. We now create one "throwaway" not-null constraint for each column
in the PK together with the CREATE TABLE command, and once the PK is
created, all those throwaway constraints are removed. This avoids
having to check each tuple for nullness when the dump restores the
primary key creation.
pg_upgrading from an older release requires a somewhat brittle procedure
to create a constraint state that matches what would be created if the
database were being created fresh in Postgres 17. I have tested all the
scenarios I could think of, and it works correctly as far as I can tell,
but I could have neglected weird cases.
This patch has been very long in the making. The first patch was
written by Bernd Helmle in 2010 to add a new pg_constraint.contype value
('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one
was killed by the realization that we ought to use contype='c' instead:
manufactured CHECK constraints. However, later SQL standard
development, as well as nonobvious emergent properties of that design
(mostly, failure to distinguish them from "normal" CHECK constraints as
well as the performance implication of having to test the CHECK
expression) led us to reconsider this choice, so now the current
implementation uses contype='n' again. During Postgres 16 this had
already been introduced by commit e056c557aef4, but there were some
problems mainly with the pg_upgrade procedure that couldn't be fixed in
reasonable time, so it was reverted.
In 2016 Vitaly Burovoy also worked on this feature[1] but found no
consensus for his proposed approach, which was claimed to be closer to
the letter of the standard, requiring an additional pg_attribute column
to track the OID of the not-null constraint for that column.
[1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Author: Bernd Helmle <mailings@oopsware.de>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
<literal>n</literal> = not-null constraint,
2020-05-14 05:03:39 +02:00
<literal>p</literal> = primary key constraint,
<literal>u</literal> = unique constraint,
<literal>t</literal> = constraint trigger,
<literal>x</literal> = exclusion constraint
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>condeferrable</structfield> <type>bool</type>
</para>
<para>
Is the constraint deferrable?
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>condeferred</structfield> <type>bool</type>
</para>
<para>
Is the constraint deferred by default?
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
2011-02-15 01:59:29 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>convalidated</structfield> <type>bool</type>
</para>
<para>
Has the constraint been validated?
2020-10-30 15:38:49 +01:00
Currently, can be false only for foreign keys and CHECK constraints
2020-05-14 05:03:39 +02:00
</para></entry>
2011-02-15 01:59:29 +01:00
</row>
2002-07-12 20:43:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
The table this constraint is on; zero if not a table constraint
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>contypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
The domain this constraint is on; zero if not a domain constraint
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
2009-07-28 04:56:31 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conindid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The index supporting this constraint, if it's a unique, primary
2021-02-02 22:15:29 +01:00
key, foreign key, or exclusion constraint; else zero
2020-05-14 05:03:39 +02:00
</para></entry>
2009-07-28 04:56:31 +02:00
</row>
2018-03-23 14:48:22 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conparentid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
The corresponding constraint of the parent partitioned table,
if this is a constraint on a partition; else zero
2020-05-14 05:03:39 +02:00
</para></entry>
2018-03-23 14:48:22 +01:00
</row>
2002-07-12 20:43:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
If a foreign key, the referenced table; else zero
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confupdtype</structfield> <type>char</type>
</para>
<para>
Foreign key update action code:
<literal>a</literal> = no action,
<literal>r</literal> = restrict,
<literal>c</literal> = cascade,
<literal>n</literal> = set null,
<literal>d</literal> = set default
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confdeltype</structfield> <type>char</type>
</para>
<para>
Foreign key deletion action code:
<literal>a</literal> = no action,
<literal>r</literal> = restrict,
<literal>c</literal> = cascade,
<literal>n</literal> = set null,
<literal>d</literal> = set default
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confmatchtype</structfield> <type>char</type>
</para>
<para>
Foreign key match type:
<literal>f</literal> = full,
<literal>p</literal> = partial,
<literal>s</literal> = simple
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
2008-05-10 01:32:05 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conislocal</structfield> <type>bool</type>
</para>
<para>
2009-12-07 06:22:23 +01:00
This constraint is defined locally for the relation. Note that a
2010-08-17 06:37:21 +02:00
constraint can be locally defined and inherited simultaneously.
2020-05-14 05:03:39 +02:00
</para></entry>
2008-05-10 01:32:05 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2023-03-28 09:58:14 +02:00
<structfield>coninhcount</structfield> <type>int2</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
2009-12-07 06:22:23 +01:00
The number of direct inheritance ancestors this constraint has.
A constraint with
2010-08-17 06:37:21 +02:00
a nonzero number of ancestors cannot be dropped nor renamed.
2020-05-14 05:03:39 +02:00
</para></entry>
2008-05-10 01:32:05 +02:00
</row>
2011-12-05 19:10:18 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>connoinherit</structfield> <type>bool</type>
</para>
<para>
2011-12-05 19:10:18 +01:00
This constraint is defined locally for the relation. It is a
non-inheritable constraint.
2020-05-14 05:03:39 +02:00
</para></entry>
2011-12-05 19:10:18 +01:00
</row>
2024-01-24 15:43:41 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2024-03-05 11:15:06 +01:00
<structfield>conperiod</structfield> <type>bool</type>
2024-01-24 15:43:41 +01:00
</para>
<para>
This constraint is defined with <literal>WITHOUT OVERLAPS</literal>
2024-03-24 07:37:13 +01:00
(for primary keys and unique constraints) or <literal>PERIOD</literal>
(for foreign keys).
2024-01-24 15:43:41 +01:00
</para></entry>
</row>
2002-07-12 20:43:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conkey</structfield> <type>int2[]</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
If a table constraint (including foreign keys, but not constraint
triggers), list of the constrained columns
</para></entry>
2018-04-09 16:53:42 +02:00
</row>
2002-07-12 20:43:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confkey</structfield> <type>int2[]</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
If a foreign key, list of the referenced columns
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
2007-02-14 02:58:58 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conpfeqop</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
If a foreign key, list of the equality operators for PK = FK comparisons
</para></entry>
2007-02-14 02:58:58 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conppeqop</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
If a foreign key, list of the equality operators for PK = PK comparisons
</para></entry>
2007-02-14 02:58:58 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conffeqop</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
If a foreign key, list of the equality operators for FK = FK comparisons
</para></entry>
2007-02-14 02:58:58 +01:00
</row>
2021-12-08 11:09:44 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confdelsetcols</structfield> <type>int2[]</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
If a foreign key with a <literal>SET NULL</literal> or <literal>SET
DEFAULT</literal> delete action, the columns that will be updated.
If null, all of the referencing columns will be updated.
</para></entry>
</row>
2009-12-07 06:22:23 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conexclop</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
If an exclusion constraint, list of the per-column exclusion operators
</para></entry>
2009-12-07 06:22:23 +01:00
</row>
2002-07-12 20:43:19 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conbin</structfield> <type>pg_node_tree</type>
</para>
<para>
If a check constraint, an internal representation of the
expression. (It's recommended to use
<function>pg_get_constraintdef()</function> to extract the definition of
a check constraint.)
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
</tbody>
</tgroup>
</table>
2009-12-07 06:22:23 +01:00
<para>
In the case of an exclusion constraint, <structfield>conkey</structfield>
is only useful for constraint elements that are simple column references.
For other cases, a zero appears in <structfield>conkey</structfield>
and the associated index must be consulted to discover the expression
that is constrained. (<structfield>conkey</structfield> thus has the
2020-09-03 13:15:53 +02:00
same contents as <link linkend="catalog-pg-index"><structname>pg_index</structname></link>.<structfield>indkey</structfield> for the
2009-12-07 06:22:23 +01:00
index.)
</para>
2002-07-12 20:43:19 +02:00
<note>
<para>
2003-04-15 15:23:35 +02:00
<literal>pg_class.relchecks</literal> needs to agree with the
2007-02-14 02:58:58 +01:00
number of check-constraint entries found in this table for each
2011-01-25 23:51:59 +01:00
relation.
2002-07-12 20:43:19 +02:00
</para>
</note>
</sect1>
2000-11-29 21:15:59 +01:00
2011-02-08 22:04:18 +01:00
2002-07-24 07:51:56 +02:00
<sect1 id="catalog-pg-conversion">
2003-04-15 15:23:35 +02:00
<title><structname>pg_conversion</structname></title>
<indexterm zone="catalog-pg-conversion">
<primary>pg_conversion</primary>
</indexterm>
2002-07-24 07:51:56 +02:00
<para>
2011-01-28 00:42:12 +01:00
The catalog <structname>pg_conversion</structname> describes
2018-08-15 17:01:39 +02:00
encoding conversion functions. See <xref linkend="sql-createconversion"/>
2005-01-06 00:42:03 +01:00
for more information.
2002-07-24 07:51:56 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_conversion</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-24 07:51:56 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-24 07:51:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conname</structfield> <type>name</type>
</para>
<para>
Conversion name (unique within a namespace)
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>connamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-07-24 07:51:56 +02:00
The OID of the namespace that contains this conversion
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the conversion
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conforencoding</structfield> <type>int4</type>
</para>
<para>
2021-10-05 05:52:51 +02:00
Source encoding ID (<link linkend="pg-encoding-to-char"><function>pg_encoding_to_char()</function></link>
can translate this number to the encoding name)
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>contoencoding</structfield> <type>int4</type>
</para>
<para>
2021-10-05 05:52:51 +02:00
Destination encoding ID (<link linkend="pg-encoding-to-char"><function>pg_encoding_to_char()</function></link>
can translate this number to the encoding name)
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conproc</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Conversion function
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>condefault</structfield> <type>bool</type>
</para>
<para>
True if this is the default conversion
</para></entry>
2002-07-24 07:51:56 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-database">
2003-04-15 15:23:35 +02:00
<title><structname>pg_database</structname></title>
<indexterm zone="catalog-pg-database">
<primary>pg_database</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2006-11-12 07:25:37 +01:00
The catalog <structname>pg_database</structname> stores information about
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
the available databases. Databases are created with the <link
linkend="sql-createdatabase"><command>CREATE DATABASE</command></link> command.
2017-11-23 15:39:47 +01:00
Consult <xref linkend="managing-databases"/> for details about the meaning
2006-11-12 07:25:37 +01:00
of some of the parameters.
2000-11-29 21:15:59 +01:00
</para>
2001-10-16 00:47:47 +02:00
<para>
Unlike most system catalogs, <structname>pg_database</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_database</structname> per cluster, not
one per database.
</para>
2000-11-29 21:15:59 +01:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_database</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Database name
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datdba</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the database, usually the user who created it
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>encoding</structfield> <type>int4</type>
</para>
<para>
Character encoding for this database
2021-10-05 05:52:51 +02:00
(<link linkend="pg-encoding-to-char"><function>pg_encoding_to_char()</function></link> can translate
2020-05-14 05:03:39 +02:00
this number to the encoding name)
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2022-05-23 10:31:33 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datlocprovider</structfield> <type>char</type>
</para>
<para>
Locale provider for this database: <literal>c</literal> = libc,
<literal>i</literal> = icu
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datistemplate</structfield> <type>bool</type>
</para>
<para>
2014-04-23 00:10:14 +02:00
If true, then this database can be cloned by
2017-10-09 03:44:17 +02:00
any user with <literal>CREATEDB</literal> privileges;
2014-04-23 00:10:14 +02:00
if false, then only superusers or the owner of
the database can clone it.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datallowconn</structfield> <type>bool</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
If false then no one can connect to this database. This is
2017-10-09 03:44:17 +02:00
used to protect the <literal>template0</literal> database from being altered.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
Add support event triggers on authenticated login
This commit introduces trigger on login event, allowing to fire some actions
right on the user connection. This can be useful for logging or connection
check purposes as well as for some personalization of environment. Usage
details are described in the documentation included, but shortly usage is
the same as for other triggers: create function returning event_trigger and
then create event trigger on login event.
In order to prevent the connection time overhead when there are no triggers
the commit introduces pg_database.dathasloginevt flag, which indicates database
has active login triggers. This flag is set by CREATE/ALTER EVENT TRIGGER
command, and unset at connection time when no active triggers found.
Author: Konstantin Knizhnik, Mikhail Gribkov
Discussion: https://postgr.es/m/0d46d29f-4558-3af9-9c85-7774e14a7709%40postgrespro.ru
Reviewed-by: Pavel Stehule, Takayuki Tsunakawa, Greg Nancarrow, Ivan Panchenko
Reviewed-by: Daniel Gustafsson, Teodor Sigaev, Robert Haas, Andres Freund
Reviewed-by: Tom Lane, Andrey Sokolov, Zhihong Yu, Sergey Shinderuk
Reviewed-by: Gregory Stark, Nikita Malakhov, Ted Yu
2023-10-16 02:16:55 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dathasloginevt</structfield> <type>bool</type>
</para>
<para>
Indicates that there are login event triggers defined for this database.
This flag is used to avoid extra lookups on the
<structname>pg_event_trigger</structname> table during each backend
startup. This flag is used internally by <productname>PostgreSQL</productname>
and should not be manually altered or read for monitoring purposes.
</para></entry>
</row>
2005-07-31 19:19:22 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datconnlimit</structfield> <type>int4</type>
</para>
<para>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
Sets maximum number of concurrent connections that can be made
Handle DROP DATABASE getting interrupted
Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.
To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.
An invalid database cannot be connected to anymore, but can still be
dropped.
Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.
Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.
Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions
2023-07-13 22:03:28 +02:00
to this database. -1 means no limit, -2 indicates the database is
invalid.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-07-31 19:19:22 +02:00
</row>
2001-08-26 18:56:03 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datfrozenxid</structfield> <type>xid</type>
</para>
<para>
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
All transaction IDs before this one have been replaced with a permanent
2017-10-09 03:44:17 +02:00
(<quote>frozen</quote>) transaction ID in this database. This is used to
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
track whether the database needs to be vacuumed in order to prevent
2017-10-09 03:44:17 +02:00
transaction ID wraparound or to allow <literal>pg_xact</literal> to be shrunk.
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
It is the minimum of the per-table
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relfrozenxid</structfield> values.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-08-26 18:56:03 +02:00
</row>
2013-06-27 21:20:33 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datminmxid</structfield> <type>xid</type>
</para>
<para>
2015-06-04 06:22:49 +02:00
All multixact IDs before this one have been replaced with a
2013-06-27 21:20:33 +02:00
transaction ID in this database. This is used to
track whether the database needs to be vacuumed in order to prevent
2017-10-09 03:44:17 +02:00
multixact ID wraparound or to allow <literal>pg_multixact</literal> to be shrunk.
2013-06-27 21:20:33 +02:00
It is the minimum of the per-table
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relminmxid</structfield> values.
2020-05-14 05:03:39 +02:00
</para></entry>
2013-06-27 21:20:33 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dattablespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2004-06-18 08:14:31 +02:00
The default tablespace for the database.
Within this database, all tables for which
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>reltablespace</structfield> is zero
2004-06-18 08:14:31 +02:00
will be stored in this tablespace; in particular, all the non-shared
2010-08-17 06:37:21 +02:00
system catalogs will be there.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2002-03-01 23:45:19 +01:00
2022-01-27 08:44:31 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datcollate</structfield> <type>text</type>
</para>
<para>
LC_COLLATE for this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datctype</structfield> <type>text</type>
</para>
<para>
LC_CTYPE for this database
</para></entry>
</row>
2022-02-14 08:09:04 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2024-03-09 23:48:18 +01:00
<structfield>datlocale</structfield> <type>text</type>
2022-03-17 14:12:03 +01:00
</para>
<para>
2024-03-09 23:48:18 +01:00
Collation provider locale name for this database. If the
provider is <literal>libc</literal>,
<structfield>datlocale</structfield> is <literal>NULL</literal>;
<structfield>datcollate</structfield> and
<structfield>datctype</structfield> are used instead.
2022-03-17 14:12:03 +01:00
</para></entry>
</row>
2023-03-08 16:35:42 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>daticurules</structfield> <type>text</type>
</para>
<para>
ICU collation rules for this database
</para></entry>
</row>
2022-03-17 14:12:03 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2022-02-14 08:09:04 +01:00
<structfield>datcollversion</structfield> <type>text</type>
</para>
<para>
Provider-specific version of the collation. This is recorded when the
database is created and then checked when it is used, to detect
changes in the collation definition that could lead to data corruption.
</para></entry>
</row>
2002-04-21 02:26:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2002-04-21 02:26:44 +02:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2010-09-17 20:49:54 +02:00
<sect1 id="catalog-pg-db-role-setting">
<title><structname>pg_db_role_setting</structname></title>
<indexterm zone="catalog-pg-db-role-setting">
<primary>pg_db_role_setting</primary>
</indexterm>
<para>
The catalog <structname>pg_db_role_setting</structname> records the default
values that have been set for run-time configuration variables,
for each role and database combination.
</para>
<para>
Unlike most system catalogs, <structname>pg_db_role_setting</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_db_role_setting</structname> per cluster, not
one per database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_db_role_setting</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2010-09-17 20:49:54 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2010-09-17 20:49:54 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>setdatabase</structfield> <type>oid</type>
(references <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the database the setting is applicable to, or zero if not database-specific
</para></entry>
2010-09-17 20:49:54 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>setrole</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the role the setting is applicable to, or zero if not role-specific
</para></entry>
2010-09-17 20:49:54 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>setconfig</structfield> <type>text[]</type>
</para>
<para>
Defaults for run-time configuration variables
</para></entry>
2010-09-17 20:49:54 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2009-10-05 21:24:49 +02:00
<sect1 id="catalog-pg-default-acl">
<title><structname>pg_default_acl</structname></title>
<indexterm zone="catalog-pg-default-acl">
<primary>pg_default_acl</primary>
</indexterm>
<para>
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_default_acl</structname> stores initial
2009-10-05 21:24:49 +02:00
privileges to be assigned to newly created objects.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_default_acl</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2009-10-05 21:24:49 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2009-10-05 21:24:49 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2009-10-05 21:24:49 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>defaclrole</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the role associated with this entry
</para></entry>
2009-10-05 21:24:49 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>defaclnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the namespace associated with this entry,
2021-02-02 22:15:29 +01:00
or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2009-10-05 21:24:49 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>defaclobjtype</structfield> <type>char</type>
</para>
<para>
2009-10-05 21:24:49 +02:00
Type of object this entry is for:
2017-10-09 03:44:17 +02:00
<literal>r</literal> = relation (table, view),
<literal>S</literal> = sequence,
<literal>f</literal> = function,
2018-08-03 22:45:08 +02:00
<literal>T</literal> = type,
<literal>n</literal> = schema
2020-05-14 05:03:39 +02:00
</para></entry>
2009-10-05 21:24:49 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>defaclacl</structfield> <type>aclitem[]</type>
</para>
<para>
2009-10-05 21:24:49 +02:00
Access privileges that this type of object should have on creation
2020-05-14 05:03:39 +02:00
</para></entry>
2009-10-05 21:24:49 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
2017-10-09 03:44:17 +02:00
A <structname>pg_default_acl</structname> entry shows the initial privileges to
2009-10-05 21:24:49 +02:00
be assigned to an object belonging to the indicated user. There are
2017-10-09 03:44:17 +02:00
currently two types of entry: <quote>global</quote> entries with
2021-02-02 22:15:29 +01:00
<structfield>defaclnamespace</structfield> = zero, and <quote>per-schema</quote> entries
2009-10-05 21:24:49 +02:00
that reference a particular schema. If a global entry is present then
2017-10-09 03:44:17 +02:00
it <emphasis>overrides</emphasis> the normal hard-wired default privileges
2009-10-05 21:24:49 +02:00
for the object type. A per-schema entry, if present, represents privileges
2017-10-09 03:44:17 +02:00
to be <emphasis>added to</emphasis> the global or hard-wired default privileges.
2009-10-05 21:24:49 +02:00
</para>
<para>
2010-08-17 06:37:21 +02:00
Note that when an ACL entry in another catalog is null, it is taken
2009-10-05 21:24:49 +02:00
to represent the hard-wired default privileges for its object,
2017-10-09 03:44:17 +02:00
<emphasis>not</emphasis> whatever might be in <structname>pg_default_acl</structname>
at the moment. <structname>pg_default_acl</structname> is only consulted during
2009-10-05 21:24:49 +02:00
object creation.
</para>
</sect1>
2002-07-12 20:43:19 +02:00
<sect1 id="catalog-pg-depend">
2003-04-15 15:23:35 +02:00
<title><structname>pg_depend</structname></title>
<indexterm zone="catalog-pg-depend">
<primary>pg_depend</primary>
</indexterm>
2002-07-12 20:43:19 +02:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_depend</structname> records the dependency
2002-07-12 20:43:19 +02:00
relationships between database objects. This information allows
2017-10-09 03:44:17 +02:00
<command>DROP</command> commands to find which other objects must be dropped
by <command>DROP CASCADE</command> or prevent dropping in the <command>DROP
RESTRICT</command> case.
2002-07-12 20:43:19 +02:00
</para>
2005-07-07 22:40:02 +02:00
<para>
See also <link linkend="catalog-pg-shdepend"><structname>pg_shdepend</structname></link>,
which performs a similar function for dependencies involving objects
that are shared across a database cluster.
</para>
2002-07-12 20:43:19 +02:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_depend</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-12 20:43:19 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-07-15 17:41:47 +02:00
The OID of the system catalog the dependent object is in
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
2021-07-15 17:41:47 +02:00
The OID of the specific dependent object
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objsubid</structfield> <type>int4</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
For a table column, this is the column number (the
2017-10-09 03:44:17 +02:00
<structfield>objid</structfield> and <structfield>classid</structfield> refer to the
2003-04-15 15:23:35 +02:00
table itself). For all other object types, this column is
2010-08-17 06:37:21 +02:00
zero.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>refclassid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog the referenced object is in
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>refobjid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the specific referenced object
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>refobjsubid</structfield> <type>int4</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
For a table column, this is the column number (the
2017-10-09 03:44:17 +02:00
<structfield>refobjid</structfield> and <structfield>refclassid</structfield> refer
2003-04-15 15:23:35 +02:00
to the table itself). For all other object types, this column
2010-08-17 06:37:21 +02:00
is zero.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>deptype</structfield> <type>char</type>
</para>
<para>
2006-01-16 19:15:31 +01:00
A code defining the specific semantics of this dependency relationship; see text
2020-05-14 05:03:39 +02:00
</para></entry>
2002-07-12 20:43:19 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
In all cases, a <structname>pg_depend</structname> entry indicates that the
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
referenced object cannot be dropped without also dropping the dependent
2002-07-12 20:43:19 +02:00
object. However, there are several subflavors identified by
2017-10-09 03:44:17 +02:00
<structfield>deptype</structfield>:
2002-07-12 20:43:19 +02:00
2003-04-15 15:23:35 +02:00
<variablelist>
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_NORMAL</symbol> (<literal>n</literal>)</term>
2003-04-15 15:23:35 +02:00
<listitem>
<para>
A normal relationship between separately-created objects. The
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
dependent object can be dropped without affecting the
referenced object. The referenced object can only be dropped
2017-10-09 03:44:17 +02:00
by specifying <literal>CASCADE</literal>, in which case the dependent
2003-04-15 15:23:35 +02:00
object is dropped, too. Example: a table column has a normal
dependency on its data type.
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_AUTO</symbol> (<literal>a</literal>)</term>
2003-04-15 15:23:35 +02:00
<listitem>
<para>
The dependent object can be dropped separately from the
referenced object, and should be automatically dropped
2017-10-09 03:44:17 +02:00
(regardless of <literal>RESTRICT</literal> or <literal>CASCADE</literal>
2003-04-15 15:23:35 +02:00
mode) if the referenced object is dropped. Example: a named
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
constraint on a table is made auto-dependent on the table, so
2003-04-15 15:23:35 +02:00
that it will go away if the table is dropped.
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_INTERNAL</symbol> (<literal>i</literal>)</term>
2003-04-15 15:23:35 +02:00
<listitem>
<para>
The dependent object was created as part of creation of the
referenced object, and is really just a part of its internal
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
implementation. A direct <command>DROP</command> of the dependent
object will be disallowed outright (we'll tell the user to issue
a <command>DROP</command> against the referenced object, instead).
A <command>DROP</command> of the referenced object will result in
automatically dropping the dependent object
whether <literal>CASCADE</literal> is specified or not. If the
2019-08-20 05:36:31 +02:00
dependent object has to be dropped due to a dependency on some other
object being removed, its drop is converted to a drop of the referenced
object, so that <literal>NORMAL</literal> and <literal>AUTO</literal>
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
dependencies of the dependent object behave much like they were
dependencies of the referenced object.
Example: a view's <literal>ON SELECT</literal> rule is made
internally dependent on the view, preventing it from being dropped
while the view remains. Dependencies of the rule (such as tables it
refers to) act as if they were dependencies of the view.
2003-04-15 15:23:35 +02:00
</para>
</listitem>
</varlistentry>
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
<varlistentry>
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
<term><symbol>DEPENDENCY_PARTITION_PRI</symbol> (<literal>P</literal>)</term>
<term><symbol>DEPENDENCY_PARTITION_SEC</symbol> (<literal>S</literal>)</term>
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
<listitem>
<para>
The dependent object was created as part of creation of the
referenced object, and is really just a part of its internal
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
implementation; however, unlike <literal>INTERNAL</literal>,
there is more than one such referenced object. The dependent object
must not be dropped unless at least one of these referenced objects
is dropped; if any one is, the dependent object should be dropped
whether or not <literal>CASCADE</literal> is specified. Also
unlike <literal>INTERNAL</literal>, a drop of some other object
that the dependent object depends on does not result in automatic
deletion of any partition-referenced object. Hence, if the drop
does not cascade to at least one of these objects via some other
path, it will be refused. (In most cases, the dependent object
shares all its non-partition dependencies with at least one
partition-referenced object, so that this restriction does not
result in blocking any cascaded delete.)
Primary and secondary partition dependencies behave identically
except that the primary dependency is preferred for use in error
messages; hence, a partition-dependent object should have one
primary partition dependency and one or more secondary partition
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
dependencies.
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
Note that partition dependencies are made in addition to, not
instead of, any dependencies the object would normally have. This
simplifies <command>ATTACH/DETACH PARTITION</command> operations:
the partition dependencies need only be added or removed.
Example: a child partitioned index is made partition-dependent
on both the partition table it is on and the parent partitioned
index, so that it goes away if either of those is dropped, but
not otherwise. The dependency on the parent index is primary,
so that if the user tries to drop the child partitioned index,
the error message will suggest dropping the parent index instead
(not the table).
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
</para>
</listitem>
</varlistentry>
2011-02-08 22:08:41 +01:00
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_EXTENSION</symbol> (<literal>e</literal>)</term>
2011-02-08 22:08:41 +01:00
<listitem>
<para>
2017-10-09 03:44:17 +02:00
The dependent object is a member of the <firstterm>extension</firstterm> that is
2011-02-08 22:08:41 +01:00
the referenced object (see
<link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>).
The dependent object can be dropped only via
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-dropextension"><command>DROP EXTENSION</command></link> on the referenced object.
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
Functionally this dependency type acts the same as
an <literal>INTERNAL</literal> dependency, but it's kept separate for
clarity and to simplify <application>pg_dump</application>.
2011-02-08 22:08:41 +01:00
</para>
</listitem>
</varlistentry>
2016-04-05 23:38:54 +02:00
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_AUTO_EXTENSION</symbol> (<literal>x</literal>)</term>
2016-04-05 23:38:54 +02:00
<listitem>
<para>
The dependent object is not a member of the extension that is the
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
referenced object (and so it should not be ignored
by <application>pg_dump</application>), but it cannot function
without the extension and should be auto-dropped if the extension is.
The dependent object may be dropped on its own as well.
Functionally this dependency type acts the same as
an <literal>AUTO</literal> dependency, but it's kept separate for
clarity and to simplify <application>pg_dump</application>.
2016-04-05 23:38:54 +02:00
</para>
</listitem>
</varlistentry>
2003-04-15 15:23:35 +02:00
</variablelist>
2002-07-12 20:43:19 +02:00
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Other dependency flavors might be needed in future.
2002-07-12 20:43:19 +02:00
</para>
Redesign the partition dependency mechanism.
The original setup for dependencies of partitioned objects had
serious problems:
1. It did not verify that a drop cascading to a partition-child object
also cascaded to at least one of the object's partition parents. Now,
normally a child object would share all its dependencies with one or
another parent (e.g. a child index's opclass dependencies would be shared
with the parent index), so that this oversight is usually harmless.
But if some dependency failed to fit this pattern, the child could be
dropped while all its parents remain, creating a logically broken
situation. (It's easy to construct artificial cases that break it,
such as attaching an unrelated extension dependency to the child object
and then dropping the extension. I'm not sure if any less-artificial
cases exist.)
2. Management of partition dependencies during ATTACH/DETACH PARTITION
was complicated and buggy; for example, after detaching a partition
table it was possible to create cases where a formerly-child index
should be dropped and was not, because the correct set of dependencies
had not been reconstructed.
Less seriously, because multiple partition relationships were
represented identically in pg_depend, there was an order-of-traversal
dependency on which partition parent was cited in error messages.
We also had some pre-existing order-of-traversal hazards for error
messages related to internal and extension dependencies. This is
cosmetic to users but causes testing problems.
To fix #1, add a check at the end of the partition tree traversal
to ensure that at least one partition parent got deleted. To fix #2,
establish a new policy that partition dependencies are in addition to,
not instead of, a child object's usual dependencies; in this way
ATTACH/DETACH PARTITION need not cope with adding or removing the
usual dependencies.
To fix the cosmetic problem, distinguish between primary and secondary
partition dependency entries in pg_depend, by giving them different
deptypes. (They behave identically except for having different
priorities for being cited in error messages.) This means that the
former 'I' dependency type is replaced with new 'P' and 'S' types.
This also fixes a longstanding bug that after handling an internal
dependency by recursing to the owning object, findDependentObjects
did not verify that the current target was now scheduled for deletion,
and did not apply the current recursion level's objflags to it.
Perhaps that should be back-patched; but in the back branches it
would only matter if some concurrent transaction had removed the
internal-linkage pg_depend entry before the recursive call found it,
or the recursive call somehow failed to find it, both of which seem
unlikely.
Catversion bump because the contents of pg_depend change for
partitioning relationships.
Patch HEAD only. It's annoying that we're not fixing #2 in v11,
but there seems no practical way to do so given that the problem
is exactly a poor choice of what entries to put in pg_depend.
We can't really fix that while staying compatible with what's
in pg_depend in existing v11 installations.
Discussion: https://postgr.es/m/CAH2-Wzkypv1R+teZrr71U23J578NnTBt2X8+Y=Odr4pOdW1rXg@mail.gmail.com
2019-02-11 20:41:13 +01:00
<para>
Note that it's quite possible for two objects to be linked by more than
one <structname>pg_depend</structname> entry. For example, a child
partitioned index would have both a partition-type dependency on its
associated partition table, and an auto dependency on each column of
that table that it indexes. This sort of situation expresses the union
of multiple dependency semantics. A dependent object can be dropped
without <literal>CASCADE</literal> if any of its dependencies satisfies
its condition for automatic dropping. Conversely, all the
dependencies' restrictions about which objects must be dropped together
must be satisfied.
</para>
2021-07-15 17:41:47 +02:00
<para>
Most objects created during <application>initdb</application> are
considered <quote>pinned</quote>, which means that the system itself
depends on them. Therefore, they are never allowed to be dropped.
Also, knowing that pinned objects will not be dropped, the dependency
mechanism doesn't bother to make <structname>pg_depend</structname>
entries showing dependencies on them. Thus, for example, a table
column of type <type>numeric</type> notionally has
a <literal>NORMAL</literal> dependency on the <type>numeric</type>
data type, but no such entry actually appears
in <structname>pg_depend</structname>.
</para>
2002-07-12 20:43:19 +02:00
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-description">
2003-04-15 15:23:35 +02:00
<title><structname>pg_description</structname></title>
<indexterm zone="catalog-pg-description">
<primary>pg_description</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_description</structname> stores optional descriptions
2005-01-06 00:42:03 +01:00
(comments) for each database object. Descriptions can be manipulated
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
with the <link linkend="sql-comment"><command>COMMENT</command></link> command and viewed with
2000-11-29 21:15:59 +01:00
<application>psql</application>'s <literal>\d</literal> commands.
2002-09-24 23:26:44 +02:00
Descriptions of many built-in system objects are provided in the initial
2003-04-15 15:23:35 +02:00
contents of <structname>pg_description</structname>.
2000-11-29 21:15:59 +01:00
</para>
2006-02-12 04:22:21 +01:00
<para>
See also <link linkend="catalog-pg-shdescription"><structname>pg_shdescription</structname></link>,
which performs a similar function for descriptions involving objects that
are shared across a database cluster.
</para>
2000-11-29 21:15:59 +01:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_description</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objoid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the object this description pertains to
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2001-08-10 20:57:42 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog this object appears in
</para></entry>
2001-08-10 20:57:42 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objsubid</structfield> <type>int4</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
For a comment on a table column, this is the column number (the
2017-10-09 03:44:17 +02:00
<structfield>objoid</structfield> and <structfield>classoid</structfield> refer to
2003-04-15 15:23:35 +02:00
the table itself). For all other object types, this column is
2010-08-17 06:37:21 +02:00
zero.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-08-10 20:57:42 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>description</structfield> <type>text</type>
</para>
<para>
Arbitrary text that serves as the description of this object
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2007-04-02 05:49:42 +02:00
<sect1 id="catalog-pg-enum">
<title><structname>pg_enum</structname></title>
<indexterm zone="catalog-pg-enum">
<primary>pg_enum</primary>
</indexterm>
<para>
The <structname>pg_enum</structname> catalog contains entries
2010-10-25 05:04:37 +02:00
showing the values and labels for each enum type. The
2007-04-02 05:49:42 +02:00
internal representation of a given enum value is actually the OID
2010-10-25 05:04:37 +02:00
of its associated row in <structname>pg_enum</structname>.
2007-04-02 05:49:42 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_enum</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2007-04-02 05:49:42 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2007-04-02 05:49:42 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2007-04-02 05:49:42 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>enumtypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-type"><structname>pg_type</structname></link> entry owning this enum value
2020-05-14 05:03:39 +02:00
</para></entry>
2007-04-02 05:49:42 +02:00
</row>
2010-10-25 05:04:37 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>enumsortorder</structfield> <type>float4</type>
</para>
<para>
The sort position of this enum value within its enum type
</para></entry>
2010-10-25 05:04:37 +02:00
</row>
2007-04-02 05:49:42 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>enumlabel</structfield> <type>name</type>
</para>
<para>
The textual label for this enum value
</para></entry>
2007-04-02 05:49:42 +02:00
</row>
</tbody>
</tgroup>
</table>
2010-10-25 05:04:37 +02:00
<para>
The OIDs for <structname>pg_enum</structname> rows follow a special
rule: even-numbered OIDs are guaranteed to be ordered in the same way
as the sort ordering of their enum type. That is, if two even OIDs
belong to the same enum type, the smaller OID must have the smaller
<structfield>enumsortorder</structfield> value. Odd-numbered OID values
need bear no relationship to the sort order. This rule allows the
enum comparison routines to avoid catalog lookups in many common cases.
The routines that create and alter enum types attempt to assign even
OIDs to enum values whenever possible.
</para>
<para>
When an enum type is created, its members are assigned sort-order
2017-10-09 03:44:17 +02:00
positions 1..<replaceable>n</replaceable>. But members added later might be given
2010-10-25 05:04:37 +02:00
negative or fractional values of <structfield>enumsortorder</structfield>.
The only requirement on these values is that they be correctly
ordered and unique within each enum type.
</para>
2007-04-02 05:49:42 +02:00
</sect1>
2007-10-01 23:10:40 +02:00
2013-12-30 19:27:51 +01:00
<sect1 id="catalog-pg-event-trigger">
<title><structname>pg_event_trigger</structname></title>
<indexterm zone="catalog-pg-event-trigger">
<primary>pg_event_trigger</primary>
</indexterm>
<para>
The catalog <structname>pg_event_trigger</structname> stores event triggers.
2017-11-23 15:39:47 +01:00
See <xref linkend="event-triggers"/> for more information.
2013-12-30 19:27:51 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_event_trigger</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2013-12-30 19:27:51 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
</thead>
<tbody>
2020-05-10 01:09:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2020-05-10 01:09:44 +02:00
</row>
2013-12-30 19:27:51 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>evtname</structfield> <type>name</type>
</para>
<para>
Trigger name (must be unique)
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>evtevent</structfield> <type>name</type>
</para>
<para>
Identifies the event for which this trigger fires
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>evtowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the event trigger
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>evtfoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The function to be called
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>evtenabled</structfield> <type>char</type>
</para>
<para>
2017-11-23 15:39:47 +01:00
Controls in which <xref linkend="guc-session-replication-role"/> modes
2013-12-30 19:27:51 +01:00
the event trigger fires.
2017-10-09 03:44:17 +02:00
<literal>O</literal> = trigger fires in <quote>origin</quote> and <quote>local</quote> modes,
<literal>D</literal> = trigger is disabled,
<literal>R</literal> = trigger fires in <quote>replica</quote> mode,
<literal>A</literal> = trigger fires always.
2020-05-14 05:03:39 +02:00
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>evttags</structfield> <type>text[]</type>
</para>
<para>
Command tags for which this trigger will fire. If NULL, the firing
of this trigger is not restricted on the basis of the command tag.
</para></entry>
2013-12-30 19:27:51 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2011-02-08 22:08:41 +01:00
<sect1 id="catalog-pg-extension">
<title><structname>pg_extension</structname></title>
<indexterm zone="catalog-pg-extension">
<primary>pg_extension</primary>
</indexterm>
<para>
The catalog <structname>pg_extension</structname> stores information
2017-11-23 15:39:47 +01:00
about the installed extensions. See <xref linkend="extend-extensions"/>
2011-02-08 22:08:41 +01:00
for details about extensions.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_extension</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2011-02-08 22:08:41 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2011-02-08 22:08:41 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extname</structfield> <type>name</type>
</para>
<para>
Name of the extension
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the extension
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Schema containing the extension's exported objects
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extrelocatable</structfield> <type>bool</type>
</para>
<para>
True if extension can be relocated to another schema
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extversion</structfield> <type>text</type>
</para>
<para>
Version name for the extension
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extconfig</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Array of <type>regclass</type> OIDs for the extension's configuration
table(s), or <literal>NULL</literal> if none
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extcondition</structfield> <type>text[]</type>
</para>
<para>
Array of <literal>WHERE</literal>-clause filter conditions for the
extension's configuration table(s), or <literal>NULL</literal> if none
</para></entry>
</row>
2011-02-08 22:08:41 +01:00
</tbody>
</tgroup>
</table>
<para>
2017-10-09 03:44:17 +02:00
Note that unlike most catalogs with a <quote>namespace</quote> column,
2011-02-08 22:08:41 +01:00
<structfield>extnamespace</structfield> is not meant to imply
that the extension belongs to that schema. Extension names are never
schema-qualified. Rather, <structfield>extnamespace</structfield>
indicates the schema that contains most or all of the extension's
objects. If <structfield>extrelocatable</structfield> is true, then
this schema must in fact contain all schema-qualifiable objects
belonging to the extension.
</para>
</sect1>
2008-12-19 17:25:19 +01:00
<sect1 id="catalog-pg-foreign-data-wrapper">
<title><structname>pg_foreign_data_wrapper</structname></title>
<indexterm zone="catalog-pg-foreign-data-wrapper">
<primary>pg_foreign_data_wrapper</primary>
</indexterm>
<para>
The catalog <structname>pg_foreign_data_wrapper</structname> stores
foreign-data wrapper definitions. A foreign-data wrapper is the
mechanism by which external data, residing on foreign servers, is
accessed.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_foreign_data_wrapper</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2008-12-19 17:25:19 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2008-12-19 17:25:19 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fdwname</structfield> <type>name</type>
</para>
<para>
Name of the foreign-data wrapper
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fdwowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the foreign-data wrapper
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
2011-02-19 06:06:18 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fdwhandler</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2011-02-19 06:06:18 +01:00
References a handler function that is responsible for
supplying execution routines for the foreign-data wrapper.
Zero if no handler is provided
2020-05-14 05:03:39 +02:00
</para></entry>
2011-02-19 06:06:18 +01:00
</row>
2008-12-19 17:25:19 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fdwvalidator</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2009-02-24 11:06:36 +01:00
References a validator function that is responsible for
2011-02-19 06:06:18 +01:00
checking the validity of the options given to the
foreign-data wrapper, as well as options for foreign servers and user
2009-02-24 11:06:36 +01:00
mappings using the foreign-data wrapper. Zero if no validator
2011-02-19 06:06:18 +01:00
is provided
2020-05-14 05:03:39 +02:00
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fdwacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fdwoptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Foreign-data wrapper specific options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="catalog-pg-foreign-server">
<title><structname>pg_foreign_server</structname></title>
<indexterm zone="catalog-pg-foreign-server">
<primary>pg_foreign_server</primary>
</indexterm>
<para>
The catalog <structname>pg_foreign_server</structname> stores
2011-02-19 06:06:18 +01:00
foreign server definitions. A foreign server describes a source
of external data, such as a remote server. Foreign
2008-12-19 17:25:19 +01:00
servers are accessed via foreign-data wrappers.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_foreign_server</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2008-12-19 17:25:19 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2008-12-19 17:25:19 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvname</structfield> <type>name</type>
</para>
<para>
Name of the foreign server
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the foreign server
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvfdw</structfield> <type>oid</type>
(references <link linkend="catalog-pg-foreign-data-wrapper"><structname>pg_foreign_data_wrapper</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the foreign-data wrapper of this foreign server
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvtype</structfield> <type>text</type>
</para>
<para>
Type of the server (optional)
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvversion</structfield> <type>text</type>
</para>
<para>
Version of the server (optional)
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srvoptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Foreign server specific options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2008-12-19 17:25:19 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2011-01-02 05:48:11 +01:00
<sect1 id="catalog-pg-foreign-table">
<title><structname>pg_foreign_table</structname></title>
<indexterm zone="catalog-pg-foreign-table">
<primary>pg_foreign_table</primary>
</indexterm>
<para>
2011-02-19 06:06:18 +01:00
The catalog <structname>pg_foreign_table</structname> contains
auxiliary information about foreign tables. A foreign table is
2020-09-03 13:15:53 +02:00
primarily represented by a
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>
entry, just like a regular table. Its <structname>pg_foreign_table</structname>
2011-02-19 06:06:18 +01:00
entry contains the information that is pertinent only to foreign tables
and not any other kind of relation.
2011-01-02 05:48:11 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_foreign_table</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2011-01-02 05:48:11 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2011-01-02 05:48:11 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ftrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry for this foreign table
2020-05-14 05:03:39 +02:00
</para></entry>
2011-01-02 05:48:11 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ftserver</structfield> <type>oid</type>
(references <link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the foreign server for this foreign table
</para></entry>
2011-01-02 05:48:11 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ftoptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Foreign table options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2011-01-02 05:48:11 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-index">
2003-04-15 15:23:35 +02:00
<title><structname>pg_index</structname></title>
<indexterm zone="catalog-pg-index">
<primary>pg_index</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_index</structname> contains part of the information
2000-11-29 21:15:59 +01:00
about indexes. The rest is mostly in
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_index</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry for this index
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry for the table this index is for
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indnatts</structfield> <type>int2</type>
</para>
<para>
The total number of columns in the index (duplicates
<literal>pg_class.relnatts</literal>); this number includes both key and included attributes
</para></entry>
2018-04-07 22:00:39 +02:00
</row>
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indnkeyatts</structfield> <type>int2</type>
</para>
<para>
The number of <firstterm>key columns</firstterm> in the index,
2018-07-18 20:43:03 +02:00
not counting any <firstterm>included columns</firstterm>, which are
2020-05-14 05:03:39 +02:00
merely stored and do not participate in the index semantics
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisunique</structfield> <type>bool</type>
</para>
<para>
If true, this is a unique index
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2022-02-03 11:29:54 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indnullsnotdistinct</structfield> <type>bool</type>
</para>
<para>
This value is only used for unique indexes. If false, this unique
index will consider null values distinct (so the index can contain
multiple null values in a column, the default PostgreSQL behavior). If
it is true, it will consider null values to be equal (so the index can
only contain one null value in a column).
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisprimary</structfield> <type>bool</type>
</para>
<para>
If true, this index represents the primary key of the table
(<structfield>indisunique</structfield> should always be true when this is true)
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2011-01-25 23:51:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisexclusion</structfield> <type>bool</type>
</para>
<para>
If true, this index supports an exclusion constraint
</para></entry>
2011-01-25 23:51:59 +01:00
</row>
2009-07-29 22:56:21 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indimmediate</structfield> <type>bool</type>
</para>
<para>
If true, the uniqueness check is enforced immediately on
2011-01-25 23:51:59 +01:00
insertion
2020-05-14 05:03:39 +02:00
(irrelevant if <structfield>indisunique</structfield> is not true)
</para></entry>
2009-07-29 22:56:21 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisclustered</structfield> <type>bool</type>
</para>
<para>
If true, the table was last clustered on this index
</para></entry>
2003-05-28 18:04:02 +02:00
</row>
2006-08-25 06:06:58 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisvalid</structfield> <type>bool</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
If true, the index is currently valid for queries. False means the
index is possibly incomplete: it must still be modified by
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-insert"><command>INSERT</command></link>/<link linkend="sql-update"><command>UPDATE</command></link> operations, but it cannot safely
2006-11-12 07:25:37 +01:00
be used for queries. If it is unique, the uniqueness property is not
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
guaranteed true either.
2020-05-14 05:03:39 +02:00
</para></entry>
2006-08-25 06:06:58 +02:00
</row>
2007-09-20 19:56:33 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indcheckxmin</structfield> <type>bool</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
If true, queries must not use the index until the <structfield>xmin</structfield>
of this <structname>pg_index</structname> row is below their <symbol>TransactionXmin</symbol>
2022-08-12 21:05:13 +02:00
event horizon, because the table may contain broken <link linkend="storage-hot">HOT chains</link> with
2007-09-20 19:56:33 +02:00
incompatible rows that they can see
2020-05-14 05:03:39 +02:00
</para></entry>
2007-09-20 19:56:33 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisready</structfield> <type>bool</type>
</para>
<para>
2007-09-20 19:56:33 +02:00
If true, the index is currently ready for inserts. False means the
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
index must be ignored by <link linkend="sql-insert"><command>INSERT</command></link>/<link linkend="sql-update"><command>UPDATE</command></link>
2010-08-17 06:37:21 +02:00
operations.
2020-05-14 05:03:39 +02:00
</para></entry>
2007-09-20 19:56:33 +02:00
</row>
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indislive</structfield> <type>bool</type>
</para>
<para>
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
If false, the index is in process of being dropped, and should be
ignored for all purposes (including HOT-safety decisions)
2020-05-14 05:03:39 +02:00
</para></entry>
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pre-drop stage was the same as the state for an
index just created by CREATE INDEX CONCURRENTLY. This meant that the
(necessary) change to make RelationGetIndexList ignore about-to-die indexes
also made it ignore freshly-created indexes; which is catastrophic because
the latter do need to be considered in HOT-safety decisions. Failure to
do so leads to incorrect index entries and subsequently wrong results from
queries depending on the concurrently-created index.
To fix, add an additional boolean column "indislive" to pg_index, so that
the freshly-created and about-to-die states can be distinguished. (This
change obviously is only possible in HEAD. This patch will need to be
back-patched, but in 9.2 we'll use a kluge consisting of overloading the
formerly-impossible state of indisvalid = true and indisready = false.)
In addition, change CREATE/DROP INDEX CONCURRENTLY so that the pg_index
flag changes they make without exclusive lock on the index are made via
heap_inplace_update() rather than a normal transactional update. The
latter is not very safe because moving the pg_index tuple could result in
concurrent SnapshotNow scans finding it twice or not at all, thus possibly
resulting in index corruption. This is a pre-existing bug in CREATE INDEX
CONCURRENTLY, which was copied into the DROP code.
In addition, fix various places in the code that ought to check to make
sure that the indexes they are manipulating are valid and/or ready as
appropriate. These represent bugs that have existed since 8.2, since
a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid
index behind, and we ought not try to do anything that might fail with
such an index.
Also fix RelationReloadIndexInfo to ensure it copies all the pg_index
columns that are allowed to change after initial creation. Previously we
could have been left with stale values of some fields in an index relcache
entry. It's not clear whether this actually had any user-visible
consequences, but it's at least a bug waiting to happen.
In addition, do some code and docs review for DROP INDEX CONCURRENTLY;
some cosmetic code cleanup but mostly addition and revision of comments.
This will need to be back-patched, but in a noticeably different form,
so I'm committing it to HEAD before working on the back-patch.
Problem reported by Amit Kapila, diagnosis by Pavan Deolassee,
fix by Tom Lane and Andres Freund.
2012-11-29 03:25:27 +01:00
</row>
2013-11-08 18:30:43 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indisreplident</structfield> <type>bool</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
If true this index has been chosen as <quote>replica identity</quote>
2020-09-03 13:15:53 +02:00
using <link linkend="sql-altertable-replica-identity"><command>ALTER TABLE ...
REPLICA IDENTITY USING INDEX ...</command></link>
2020-05-14 05:03:39 +02:00
</para></entry>
2013-11-08 18:30:43 +01:00
</row>
2005-03-29 02:17:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indkey</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
2005-03-29 02:17:27 +02:00
This is an array of <structfield>indnatts</structfield> values that
Allow specifying column lists for logical replication
This allows specifying an optional column list when adding a table to
logical replication. The column list may be specified after the table
name, enclosed in parentheses. Columns not included in this list are not
sent to the subscriber, allowing the schema on the subscriber to be a
subset of the publisher schema.
For UPDATE/DELETE publications, the column list needs to cover all
REPLICA IDENTITY columns. For INSERT publications, the column list is
arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if
the table uses REPLICA IDENTITY FULL, column list is not allowed.
The column list can contain only simple column references. Complex
expressions, function calls etc. are not allowed. This restriction could
be relaxed in the future.
During the initial table synchronization, only columns included in the
column list are copied to the subscriber. If the subscription has
several publications, containing the same table with different column
lists, columns specified in any of the lists will be copied.
This means all columns are replicated if the table has no column list
at all (which is treated as column list with all columns), or when of
the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that
matches the schema of the table).
For partitioned tables, publish_via_partition_root determines whether
the column list for the root or the leaf relation will be used. If the
parameter is 'false' (the default), the list defined for the leaf
relation is used. Otherwise, the column list for the root partition
will be used.
Psql commands \dRp+ and \d <table-name> now display any column lists.
Author: Tomas Vondra, Alvaro Herrera, Rahila Syed
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed,
Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
indicate which table columns this index indexes. For example, a value
2005-03-29 02:17:27 +02:00
of <literal>1 3</literal> would mean that the first and the third table
2018-07-18 20:43:03 +02:00
columns make up the index entries. Key columns come before non-key
(included) columns. A zero in this array indicates that the
2005-03-29 02:17:27 +02:00
corresponding index attribute is an expression over the table columns,
2010-08-17 06:37:21 +02:00
rather than a simple column reference.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-03-29 02:17:27 +02:00
</row>
2011-02-08 22:04:18 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indcollation</structfield> <type>oidvector</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2018-07-18 20:43:03 +02:00
For each column in the index key
(<structfield>indnkeyatts</structfield> values), this contains the OID
of the collation to use for the index, or zero if the column is not of
a collatable data type.
2020-05-14 05:03:39 +02:00
</para></entry>
2011-02-08 22:04:18 +01:00
</row>
2005-03-29 02:17:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indclass</structfield> <type>oidvector</type>
(references <link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2018-07-18 20:43:03 +02:00
For each column in the index key
(<structfield>indnkeyatts</structfield> values), this contains the OID
of the operator class to use. See
2010-08-17 06:37:21 +02:00
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link> for details.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-03-29 02:17:27 +02:00
</row>
2007-01-09 03:14:16 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indoption</structfield> <type>int2vector</type>
</para>
<para>
2018-07-18 20:43:03 +02:00
This is an array of <structfield>indnkeyatts</structfield> values that
2007-01-09 03:14:16 +01:00
store per-column flag bits. The meaning of the bits is defined by
2010-08-17 06:37:21 +02:00
the index's access method.
2020-05-14 05:03:39 +02:00
</para></entry>
2007-01-09 03:14:16 +01:00
</row>
2003-05-28 18:04:02 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexprs</structfield> <type>pg_node_tree</type>
</para>
<para>
2010-08-17 06:37:21 +02:00
Expression trees (in <function>nodeToString()</function>
representation) for index attributes that are not simple column
references. This is a list with one element for each zero
2017-10-09 03:44:17 +02:00
entry in <structfield>indkey</structfield>. Null if all index attributes
2010-08-17 06:37:21 +02:00
are simple references.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indpred</structfield> <type>pg_node_tree</type>
</para>
<para>
2010-08-17 06:37:21 +02:00
Expression tree (in <function>nodeToString()</function>
representation) for partial index predicate. Null if not a
partial index.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-inherits">
2003-04-15 15:23:35 +02:00
<title><structname>pg_inherits</structname></title>
<indexterm zone="catalog-pg-inherits">
<primary>pg_inherits</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_inherits</structname> records information about
2020-07-30 08:48:44 +02:00
table and index inheritance hierarchies. There is one entry for each direct
parent-child table or index relationship in the database. (Indirect
inheritance can be determined by following chains of entries.)
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_inherits</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inhrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-07-30 08:48:44 +02:00
The OID of the child table or index
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inhparent</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-07-30 08:48:44 +02:00
The OID of the parent table or index
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inhseqno</structfield> <type>int4</type>
</para>
<para>
2005-01-06 00:42:03 +01:00
If there is more than one direct parent for a child table (multiple
2000-11-29 21:15:59 +01:00
inheritance), this number tells the order in which the
2010-08-17 06:37:21 +02:00
inherited columns are to be arranged. The count starts at 1.
2020-07-30 08:48:44 +02:00
</para>
<para>
2020-12-24 09:05:49 +01:00
Indexes cannot have multiple inheritance, since they can only inherit
2020-07-30 08:48:44 +02:00
when using declarative partitioning.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY
Allow a partition be detached from its partitioned table without
blocking concurrent queries, by running in two transactions and only
requiring ShareUpdateExclusive in the partitioned table.
Because it runs in two transactions, it cannot be used in a transaction
block. This is the main reason to use dedicated syntax: so that users
can choose to use the original mode if they need it. But also, it
doesn't work when a default partition exists (because an exclusive lock
would still need to be obtained on it, in order to change its partition
constraint.)
In case the second transaction is cancelled or a crash occurs, there's
ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final
steps.
The main trick to make this work is the addition of column
pg_inherits.inhdetachpending, initially false; can only be set true in
the first part of this command. Once that is committed, concurrent
transactions that use a PartitionDirectory will include or ignore
partitions so marked: in optimizer they are ignored if the row is marked
committed for the snapshot; in executor they are always included. As a
result, and because of the way PartitionDirectory caches partition
descriptors, queries that were planned before the detach will see the
rows in the detached partition and queries that are planned after the
detach, won't.
A CHECK constraint is created that duplicates the partition constraint.
This is probably not strictly necessary, and some users will prefer to
remove it afterwards, but if the partition is re-attached to a
partitioned table, the constraint needn't be rechecked.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inhdetachpending</structfield> <type>bool</type>
</para>
<para>
<literal>true</literal> for a partition that is in the process of
being detached; <literal>false</literal> otherwise.
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
</tbody>
2016-04-07 03:45:32 +02:00
</tgroup>
</table>
</sect1>
<sect1 id="catalog-pg-init-privs">
<title><structname>pg_init_privs</structname></title>
<indexterm zone="catalog-pg-init-privs">
<primary>pg_init_privs</primary>
</indexterm>
<para>
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_init_privs</structname> records information about
2016-04-07 03:45:32 +02:00
the initial privileges of objects in the system. There is one entry
for each object in the database which has a non-default (non-NULL)
initial set of privileges.
</para>
<para>
Objects can have initial privileges either by having those privileges set
2017-10-09 03:44:17 +02:00
when the system is initialized (by <application>initdb</application>) or when the
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
object is created during a <link linkend="sql-createextension"><command>CREATE EXTENSION</command></link> and the
extension script sets initial privileges using the <link linkend="sql-grant"><command>GRANT</command></link>
2016-04-07 03:45:32 +02:00
system. Note that the system will automatically handle recording of the
privileges during the extension script and that extension authors need
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
only use the <command>GRANT</command> and <command>REVOKE</command>
2016-04-07 03:45:32 +02:00
statements in their script to have the privileges recorded. The
<literal>privtype</literal> column indicates if the initial privilege was
2017-10-09 03:44:17 +02:00
set by <application>initdb</application> or during a
2016-04-07 03:45:32 +02:00
<command>CREATE EXTENSION</command> command.
</para>
<para>
2017-10-09 03:44:17 +02:00
Objects which have initial privileges set by <application>initdb</application> will
2016-04-07 03:45:32 +02:00
have entries where <literal>privtype</literal> is
<literal>'i'</literal>, while objects which have initial privileges set
by <command>CREATE EXTENSION</command> will have entries where
<literal>privtype</literal> is <literal>'e'</literal>.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_init_privs</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2016-04-07 03:45:32 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2016-04-07 03:45:32 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objoid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the specific object
</para></entry>
2016-04-07 03:45:32 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog the object is in
</para></entry>
2016-04-07 03:45:32 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objsubid</structfield> <type>int4</type>
</para>
<para>
2016-04-07 03:45:32 +02:00
For a table column, this is the column number (the
2017-10-09 03:44:17 +02:00
<structfield>objoid</structfield> and <structfield>classoid</structfield> refer to the
2016-04-07 03:45:32 +02:00
table itself). For all other object types, this column is
zero.
2020-05-14 05:03:39 +02:00
</para></entry>
2016-04-07 03:45:32 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>privtype</structfield> <type>char</type>
</para>
<para>
2016-04-07 03:45:32 +02:00
A code defining the type of initial privilege of this object; see text
2020-05-14 05:03:39 +02:00
</para></entry>
2016-04-07 03:45:32 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>initprivs</structfield> <type>aclitem[]</type>
</para>
<para>
2016-04-07 03:45:32 +02:00
The initial access privileges; see
2018-12-03 17:40:49 +01:00
<xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2016-04-07 03:45:32 +02:00
</row>
</tbody>
2000-11-29 21:15:59 +01:00
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-language">
2003-04-15 15:23:35 +02:00
<title><structname>pg_language</structname></title>
<indexterm zone="catalog-pg-language">
<primary>pg_language</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2005-01-06 00:42:03 +01:00
The catalog <structname>pg_language</structname> registers
2000-11-29 21:15:59 +01:00
languages in which you can write functions or stored procedures.
2017-11-23 15:39:47 +01:00
See <xref linkend="sql-createlanguage"/>
and <xref linkend="xplang"/> for more information about language handlers.
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_language</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanname</structfield> <type>name</type>
</para>
<para>
Name of the language
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2007-03-26 18:58:41 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the language
</para></entry>
2007-03-26 18:58:41 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanispl</structfield> <type>bool</type>
</para>
<para>
2002-12-17 18:41:30 +01:00
This is false for internal languages (such as
<acronym>SQL</acronym>) and true for user-defined languages.
Currently, <application>pg_dump</application> still uses this
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
to determine which languages need to be dumped, but this might be
2010-08-17 06:37:21 +02:00
replaced by a different mechanism in the future.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanpltrusted</structfield> <type>bool</type>
</para>
<para>
2005-05-06 16:28:53 +02:00
True if this is a trusted language, which means that it is believed
not to grant access to anything outside the normal SQL execution
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
environment. Only superusers can create functions in untrusted
2010-08-17 06:37:21 +02:00
languages.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanplcallfoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2003-04-15 15:23:35 +02:00
For noninternal languages this references the language
2000-11-29 21:15:59 +01:00
handler, which is a special function that is responsible for
executing all functions that are written in the particular
2021-02-02 22:15:29 +01:00
language. Zero for internal languages.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2009-09-23 01:43:43 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>laninline</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2009-09-23 01:43:43 +02:00
This references a function that is responsible for executing
2017-10-09 03:44:17 +02:00
<quote>inline</quote> anonymous code blocks
2017-11-23 15:39:47 +01:00
(<xref linkend="sql-do"/> blocks).
2010-08-17 06:37:21 +02:00
Zero if inline blocks are not supported.
2020-05-14 05:03:39 +02:00
</para></entry>
2009-09-23 01:43:43 +02:00
</row>
2002-06-20 17:44:06 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanvalidator</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-06-20 17:44:06 +02:00
This references a language validator function that is responsible
for checking the syntax and validity of new functions when they
2010-08-17 06:37:21 +02:00
are created. Zero if no validator is provided.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-06-20 17:44:06 +02:00
</row>
2002-02-19 00:11:58 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lanacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2002-02-19 00:11:58 +01:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-largeobject">
2003-04-15 15:23:35 +02:00
<title><structname>pg_largeobject</structname></title>
<indexterm zone="catalog-pg-largeobject">
<primary>pg_largeobject</primary>
</indexterm>
2001-10-16 00:47:47 +02:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_largeobject</structname> holds the data making up
2009-12-17 15:36:16 +01:00
<quote>large objects</quote>. A large object is identified by an OID
assigned when it is created. Each large object is broken into
2017-10-09 03:44:17 +02:00
segments or <quote>pages</quote> small enough to be conveniently stored as rows
2001-10-16 00:47:47 +02:00
in <structname>pg_largeobject</structname>.
2017-10-09 03:44:17 +02:00
The amount of data per page is defined to be <symbol>LOBLKSIZE</symbol> (which is currently
<literal>BLCKSZ/4</literal>, or typically 2 kB).
2001-10-16 00:47:47 +02:00
</para>
2009-12-11 04:34:57 +01:00
<para>
2017-10-09 03:44:17 +02:00
Prior to <productname>PostgreSQL</productname> 9.0, there was no permission structure
2009-12-17 15:36:16 +01:00
associated with large objects. As a result,
<structname>pg_largeobject</structname> was publicly readable and could be
used to obtain the OIDs (and contents) of all large objects in the system.
This is no longer the case; use
2017-10-09 03:44:17 +02:00
<link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</structname></link>
2009-12-17 15:36:16 +01:00
to obtain a list of large object OIDs.
2009-12-11 04:34:57 +01:00
</para>
2001-10-16 00:47:47 +02:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_largeobject</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2001-10-16 00:47:47 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>loid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Identifier of the large object that includes this page
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pageno</structfield> <type>int4</type>
</para>
<para>
Page number of this page within its large object
(counting from zero)
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>data</structfield> <type>bytea</type>
</para>
<para>
2001-10-16 00:47:47 +02:00
Actual data stored in the large object.
2017-10-09 03:44:17 +02:00
This will never be more than <symbol>LOBLKSIZE</symbol> bytes and might be less.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
Each row of <structname>pg_largeobject</structname> holds data
for one page of a large object, beginning at
2017-10-09 03:44:17 +02:00
byte offset (<literal>pageno * LOBLKSIZE</literal>) within the object. The implementation
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
allows sparse storage: pages might be missing, and might be shorter than
2017-10-09 03:44:17 +02:00
<literal>LOBLKSIZE</literal> bytes even if they are not the last page of the object.
2001-10-16 00:47:47 +02:00
Missing regions within a large object read as zeroes.
</para>
2001-11-09 00:44:01 +01:00
</sect1>
2001-10-16 00:47:47 +02:00
2009-12-11 04:34:57 +01:00
<sect1 id="catalog-pg-largeobject-metadata">
<title><structname>pg_largeobject_metadata</structname></title>
<indexterm zone="catalog-pg-largeobject-metadata">
<primary>pg_largeobject_metadata</primary>
</indexterm>
<para>
2009-12-17 15:36:16 +01:00
The catalog <structname>pg_largeobject_metadata</structname>
holds metadata associated with large objects. The actual large object
data is stored in
2017-10-09 03:44:17 +02:00
<link linkend="catalog-pg-largeobject"><structname>pg_largeobject</structname></link>.
2009-12-11 04:34:57 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_largeobject_metadata</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2009-12-11 04:34:57 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2009-12-11 04:34:57 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2009-12-11 04:34:57 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lomowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the large object
</para></entry>
2009-12-11 04:34:57 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lomacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2009-12-11 04:34:57 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2001-10-16 00:47:47 +02:00
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
2002-03-22 22:34:44 +01:00
<sect1 id="catalog-pg-namespace">
2003-04-15 15:23:35 +02:00
<title><structname>pg_namespace</structname></title>
<indexterm zone="catalog-pg-namespace">
<primary>pg_namespace</primary>
</indexterm>
2002-03-22 22:34:44 +01:00
<para>
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_namespace</structname> stores namespaces.
2003-04-15 15:23:35 +02:00
A namespace is the structure underlying SQL schemas: each namespace
can have a separate collection of relations, types, etc. without name
2002-03-22 22:34:44 +01:00
conflicts.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_namespace</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-03-22 22:34:44 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-03-22 22:34:44 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-03-22 22:34:44 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>nspname</structfield> <type>name</type>
</para>
<para>
Name of the namespace
</para></entry>
2002-03-22 22:34:44 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>nspowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the namespace
</para></entry>
2002-03-22 22:34:44 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>nspacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2002-03-22 22:34:44 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2002-07-30 07:24:56 +02:00
<sect1 id="catalog-pg-opclass">
2003-04-15 15:23:35 +02:00
<title><structname>pg_opclass</structname></title>
<indexterm zone="catalog-pg-opclass">
<primary>pg_opclass</primary>
</indexterm>
2002-07-30 07:24:56 +02:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_opclass</structname> defines
2002-07-30 07:24:56 +02:00
index access method operator classes. Each operator class defines
2003-04-15 15:23:35 +02:00
semantics for index columns of a particular data type and a particular
2006-12-23 01:43:13 +01:00
index access method. An operator class essentially specifies that a
particular operator family is applicable to a particular indexable column
data type. The set of operators from the family that are actually usable
with the indexed column are whichever ones accept the column's data type
2012-06-07 23:06:20 +02:00
as their left-hand input.
2002-07-30 07:24:56 +02:00
</para>
<para>
2017-11-23 15:39:47 +01:00
Operator classes are described at length in <xref linkend="xindex"/>.
2002-07-30 07:24:56 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_opclass</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2002-07-30 07:24:56 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcmethod</structfield> <type>oid</type>
(references <link linkend="catalog-pg-am"><structname>pg_am</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Index access method operator class is for
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcname</structfield> <type>name</type>
</para>
<para>
Name of this operator class
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Namespace of this operator class
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the operator class
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
2006-12-23 01:43:13 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcfamily</structfield> <type>oid</type>
(references <link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Operator family containing the operator class
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
2002-07-30 07:24:56 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcintype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type that the operator class indexes
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opcdefault</structfield> <type>bool</type>
</para>
<para>
True if this operator class is the default for <structfield>opcintype</structfield>
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opckeytype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Type of data stored in index, or zero if same as <structfield>opcintype</structfield>
</para></entry>
2002-07-30 07:24:56 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
2017-10-09 03:44:17 +02:00
An operator class's <structfield>opcmethod</structfield> must match the
2020-06-22 06:40:04 +02:00
<structfield>opfmethod</structfield> of its containing operator family.
2006-12-23 01:43:13 +01:00
Also, there must be no more than one <structname>pg_opclass</structname>
2020-06-22 06:40:04 +02:00
row having <structfield>opcdefault</structfield> true for any given combination of
<structfield>opcmethod</structfield> and <structfield>opcintype</structfield>.
2002-07-30 07:24:56 +02:00
</para>
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-operator">
2003-04-15 15:23:35 +02:00
<title><structname>pg_operator</structname></title>
<indexterm zone="catalog-pg-operator">
<primary>pg_operator</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_operator</structname> stores information about operators.
2017-11-23 15:39:47 +01:00
See <xref linkend="sql-createoperator"/>
and <xref linkend="xoper"/> for more information.
2000-11-29 21:15:59 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_operator</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprname</structfield> <type>name</type>
</para>
<para>
Name of the operator
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2002-04-17 01:08:12 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-04-17 01:08:12 +02:00
The OID of the namespace that contains this operator
2020-05-14 05:03:39 +02:00
</para></entry>
2002-04-17 01:08:12 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the operator
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprkind</structfield> <type>char</type>
</para>
<para>
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
<literal>b</literal> = infix operator (<quote>both</quote>),
or <literal>l</literal> = prefix operator (<quote>left</quote>)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2006-12-23 01:43:13 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprcanmerge</structfield> <type>bool</type>
</para>
<para>
This operator supports merge joins
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprcanhash</structfield> <type>bool</type>
</para>
<para>
This operator supports hash joins
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprleft</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Type of the left operand (zero for a prefix operator)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprright</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Type of the right operand
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprresult</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Type of the result
2021-02-02 22:15:29 +01:00
(zero for a not-yet-defined <quote>shell</quote> operator)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprcom</structfield> <type>oid</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Commutator of this operator (zero if none)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprnegate</structfield> <type>oid</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Negator of this operator (zero if none)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprcode</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Function that implements this operator
2021-02-02 22:15:29 +01:00
(zero for a not-yet-defined <quote>shell</quote> operator)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprrest</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Restriction selectivity estimation function for this operator
2021-02-02 22:15:29 +01:00
(zero if none)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oprjoin</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Join selectivity estimation function for this operator
2021-02-02 22:15:29 +01:00
(zero if none)
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2006-12-23 01:43:13 +01:00
<sect1 id="catalog-pg-opfamily">
<title><structname>pg_opfamily</structname></title>
<indexterm zone="catalog-pg-opfamily">
<primary>pg_opfamily</primary>
</indexterm>
<para>
The catalog <structname>pg_opfamily</structname> defines operator families.
Each operator family is a collection of operators and associated
support routines that implement the semantics specified for a particular
index access method. Furthermore, the operators in a family are all
2017-10-09 03:44:17 +02:00
<quote>compatible</quote>, in a way that is specified by the access method.
2006-12-23 01:43:13 +01:00
The operator family concept allows cross-data-type operators to be used
with indexes and to be reasoned about using knowledge of access method
semantics.
</para>
<para>
2017-11-23 15:39:47 +01:00
Operator families are described at length in <xref linkend="xindex"/>.
2006-12-23 01:43:13 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_opfamily</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2006-12-23 01:43:13 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2006-12-23 01:43:13 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opfmethod</structfield> <type>oid</type>
(references <link linkend="catalog-pg-am"><structname>pg_am</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Index access method operator family is for
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opfname</structfield> <type>name</type>
</para>
<para>
Name of this operator family
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opfnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Namespace of this operator family
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>opfowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the operator family
</para></entry>
2006-12-23 01:43:13 +01:00
</row>
</tbody>
</tgroup>
</table>
<para>
The majority of the information defining an operator family is not in its
<structname>pg_opfamily</structname> row, but in the associated rows in
<link linkend="catalog-pg-amop"><structname>pg_amop</structname></link>,
<link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link>,
and
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.
</para>
</sect1>
2022-04-06 19:24:33 +02:00
<sect1 id="catalog-pg-parameter-acl">
<title><structname>pg_parameter_acl</structname></title>
<indexterm zone="catalog-pg-parameter-acl">
<primary>pg_parameter_acl</primary>
</indexterm>
<para>
The catalog <structname>pg_parameter_acl</structname> records configuration
parameters for which privileges have been granted to one or more roles.
No entry is made for parameters that have default privileges.
</para>
<para>
Unlike most system catalogs, <structname>pg_parameter_acl</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_parameter_acl</structname> per cluster, not
one per database.
</para>
<table>
<title><structname>pg_parameter_acl</structname> Columns</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>parname</structfield> <type>text</type>
</para>
<para>
The name of a configuration parameter for which privileges are granted
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>paracl</structfield> <type>aclitem[]</type>
</para>
<para>
Access privileges; see <xref linkend="ddl-priv"/> for details
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
2017-05-15 01:15:52 +02:00
<sect1 id="catalog-pg-partitioned-table">
<title><structname>pg_partitioned_table</structname></title>
<indexterm zone="catalog-pg-partitioned-table">
<primary>pg_partitioned_table</primary>
</indexterm>
<para>
The catalog <structname>pg_partitioned_table</structname> stores
information about how tables are partitioned.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_partitioned_table</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2017-05-15 01:15:52 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry for this partitioned table
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partstrat</structfield> <type>char</type>
</para>
<para>
2018-05-07 15:48:47 +02:00
Partitioning strategy; <literal>h</literal> = hash partitioned table,
<literal>l</literal> = list partitioned table, <literal>r</literal> = range partitioned table
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partnatts</structfield> <type>int2</type>
</para>
<para>
2021-02-02 22:15:29 +01:00
The number of columns in the partition key
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partdefid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry for the default partition
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
of this partitioned table, or zero if this partitioned table does not
2021-02-02 22:15:29 +01:00
have a default partition
2020-05-14 05:03:39 +02:00
</para></entry>
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
</row>
2017-05-15 01:15:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partattrs</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
2017-05-15 01:15:52 +02:00
This is an array of <structfield>partnatts</structfield> values that
indicate which table columns are part of the partition key. For
example, a value of <literal>1 3</literal> would mean that the first
and the third table columns make up the partition key. A zero in this
array indicates that the corresponding partition key column is an
expression, rather than a simple column reference.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partclass</structfield> <type>oidvector</type>
(references <link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2017-05-15 01:15:52 +02:00
For each column in the partition key, this contains the OID of the
operator class to use. See
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link> for details.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partcollation</structfield> <type>oidvector</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2017-05-15 01:15:52 +02:00
For each column in the partition key, this contains the OID of the
2017-06-06 18:24:44 +02:00
collation to use for partitioning, or zero if the column is not
2017-06-06 17:07:20 +02:00
of a collatable data type.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partexprs</structfield> <type>pg_node_tree</type>
</para>
<para>
2017-05-15 01:15:52 +02:00
Expression trees (in <function>nodeToString()</function>
representation) for partition key columns that are not simple column
references. This is a list with one element for each zero
2017-10-09 03:44:17 +02:00
entry in <structfield>partattrs</structfield>. Null if all partition key columns
2017-05-15 01:15:52 +02:00
are simple references.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2015-01-24 22:16:22 +01:00
<sect1 id="catalog-pg-policy">
<title><structname>pg_policy</structname></title>
<indexterm zone="catalog-pg-policy">
<primary>pg_policy</primary>
</indexterm>
<para>
2021-04-21 08:14:43 +02:00
The catalog <structname>pg_policy</structname> stores row-level
2015-01-24 22:16:22 +01:00
security policies for tables. A policy includes the kind of
command that it applies to (possibly all commands), the roles that it
applies to, the expression to be added as a security-barrier
qualification to queries that include the table, and the expression
2017-10-09 03:44:17 +02:00
to be added as a <literal>WITH CHECK</literal> option for queries that attempt to
2015-01-24 22:16:22 +01:00
add new records to the table.
</para>
<table>
<title><structname>pg_policy</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2015-01-24 22:16:22 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
</thead>
<tbody>
2020-05-10 01:09:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2020-05-10 01:09:44 +02:00
</row>
2015-01-24 22:16:22 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polname</structfield> <type>name</type>
</para>
<para>
The name of the policy
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table to which the policy applies
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polcmd</structfield> <type>char</type>
</para>
<para>
The command type to which the policy is applied:
2020-09-03 13:15:53 +02:00
<literal>r</literal> for <xref linkend="sql-select"/>,
<literal>a</literal> for <xref linkend="sql-insert"/>,
<literal>w</literal> for <xref linkend="sql-update"/>,
<literal>d</literal> for <xref linkend="sql-delete"/>,
2020-05-14 05:03:39 +02:00
or <literal>*</literal> for all
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
2016-12-05 21:50:55 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polpermissive</structfield> <type>bool</type>
</para>
<para>
Is the policy permissive or restrictive?
</para></entry>
2016-12-05 21:50:55 +01:00
</row>
2015-01-24 22:16:22 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polroles</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
The roles to which the policy is applied;
zero means <literal>PUBLIC</literal>
(and normally appears alone in the array)
2020-05-14 05:03:39 +02:00
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polqual</structfield> <type>pg_node_tree</type>
</para>
<para>
The expression tree to be added to the security barrier qualifications for queries that use the table
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>polwithcheck</structfield> <type>pg_node_tree</type>
</para>
<para>
The expression tree to be added to the WITH CHECK qualifications for queries that attempt to add rows to the table
</para></entry>
2015-01-24 22:16:22 +01:00
</row>
</tbody>
</tgroup>
</table>
<note>
<para>
2017-10-09 03:44:17 +02:00
Policies stored in <structname>pg_policy</structname> are applied only when
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relrowsecurity</structfield> is set for
2015-01-24 22:16:22 +01:00
their table.
</para>
</note>
</sect1>
2005-09-08 22:07:42 +02:00
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-proc">
2003-04-15 15:23:35 +02:00
<title><structname>pg_proc</structname></title>
<indexterm zone="catalog-pg-proc">
<primary>pg_proc</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2018-03-02 14:57:38 +01:00
The catalog <structname>pg_proc</structname> stores information about
functions, procedures, aggregate functions, and window functions
(collectively also known as routines). See <xref
linkend="sql-createfunction"/>, <xref linkend="sql-createprocedure"/>, and
<xref linkend="xfunc"/> for more information.
2000-11-29 21:15:59 +01:00
</para>
2002-04-11 22:00:18 +02:00
<para>
2018-03-02 14:57:38 +01:00
If <structfield>prokind</structfield> indicates that the entry is for an
aggregate function, there should be a matching row in
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-aggregate"><structfield>pg_aggregate</structfield></link>.
2002-04-11 22:00:18 +02:00
</para>
2000-11-29 21:15:59 +01:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_proc</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proname</structfield> <type>name</type>
</para>
<para>
Name of the function
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2002-04-05 02:31:36 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pronamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-04-05 02:31:36 +02:00
The OID of the namespace that contains this function
2020-05-14 05:03:39 +02:00
</para></entry>
2002-04-05 02:31:36 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the function
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prolang</structfield> <type>oid</type>
(references <link linkend="catalog-pg-language"><structname>pg_language</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Implementation language or call interface of this function
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2007-01-22 02:35:23 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>procost</structfield> <type>float4</type>
</para>
<para>
Estimated execution cost (in units of
2017-11-23 15:39:47 +01:00
<xref linkend="guc-cpu-operator-cost"/>); if <structfield>proretset</structfield>,
2020-05-14 05:03:39 +02:00
this is cost per row returned
</para></entry>
2007-01-22 02:35:23 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prorows</structfield> <type>float4</type>
</para>
<para>
Estimated number of result rows (zero if not <structfield>proretset</structfield>)
</para></entry>
2007-01-22 02:35:23 +01:00
</row>
2008-07-16 18:55:24 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>provariadic</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type of the variadic array parameter's elements,
or zero if the function does not have a variadic parameter
</para></entry>
2008-07-16 18:55:24 +02:00
</row>
2011-06-22 04:15:24 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prosupport</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Planner support function for this function
(see <xref linkend="xfunc-optimization"/>), or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2011-06-22 04:15:24 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prokind</structfield> <type>char</type>
</para>
<para>
<literal>f</literal> for a normal function, <literal>p</literal>
for a procedure, <literal>a</literal> for an aggregate function, or
<literal>w</literal> for a window function
</para></entry>
2008-12-19 19:25:20 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prosecdef</structfield> <type>bool</type>
</para>
<para>
Function is a security definer (i.e., a <quote>setuid</quote>
function)
</para></entry>
2012-02-14 04:20:27 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proleakproof</structfield> <type>bool</type>
</para>
<para>
2012-02-14 04:20:27 +01:00
The function has no side effects. No information about the
arguments is conveyed except via the return value. Any function
that might throw an error depending on the values of its arguments
2012-06-07 23:06:20 +02:00
is not leak-proof.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proisstrict</structfield> <type>bool</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
Function returns null if any call argument is null. In that
case the function won't actually be called at all. Functions
that are not <quote>strict</quote> must be prepared to handle
2010-08-17 06:37:21 +02:00
null inputs.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2002-04-11 22:00:18 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proretset</structfield> <type>bool</type>
</para>
<para>
Function returns a set (i.e., multiple values of the specified
data type)
</para></entry>
2002-04-11 22:00:18 +02:00
</row>
2002-04-05 02:31:36 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>provolatile</structfield> <type>char</type>
</para>
<para>
2002-04-05 02:31:36 +02:00
<structfield>provolatile</structfield> tells whether the function's
result depends only on its input arguments, or is affected by outside
factors.
2017-10-09 03:44:17 +02:00
It is <literal>i</literal> for <quote>immutable</quote> functions,
2002-04-05 02:31:36 +02:00
which always deliver the same result for the same inputs.
2017-10-09 03:44:17 +02:00
It is <literal>s</literal> for <quote>stable</quote> functions,
2002-04-05 02:31:36 +02:00
whose results (for fixed inputs) do not change within a scan.
2017-10-09 03:44:17 +02:00
It is <literal>v</literal> for <quote>volatile</quote> functions,
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
whose results might change at any time. (Use <literal>v</literal> also
2002-04-05 02:31:36 +02:00
for functions with side-effects, so that calls to them cannot get
optimized away.)
2020-05-14 05:03:39 +02:00
</para></entry>
2002-04-05 02:31:36 +02:00
</row>
2015-09-16 21:38:47 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proparallel</structfield> <type>char</type>
</para>
<para>
2015-09-16 21:38:47 +02:00
<structfield>proparallel</structfield> tells whether the function
can be safely run in parallel mode.
It is <literal>s</literal> for functions which are safe to run in
parallel mode without restriction.
It is <literal>r</literal> for functions which can be run in parallel
mode, but their execution is restricted to the parallel group leader;
parallel worker processes cannot invoke these functions.
It is <literal>u</literal> for functions which are unsafe in parallel
mode; the presence of such a function forces a serial execution plan.
2020-05-14 05:03:39 +02:00
</para></entry>
2015-09-16 21:38:47 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pronargs</structfield> <type>int2</type>
</para>
<para>
Number of input arguments
</para></entry>
2008-12-18 19:20:35 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pronargdefaults</structfield> <type>int2</type>
</para>
<para>
Number of arguments that have defaults
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prorettype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type of the return value
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proargtypes</structfield> <type>oidvector</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-01-25 17:20:17 +01:00
An array of the data types of the function arguments. This includes
2008-07-16 03:30:23 +02:00
only input arguments (including <literal>INOUT</literal> and
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
<literal>VARIADIC</literal> arguments), and thus represents
the call signature of the function.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-03-29 21:44:23 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proallargtypes</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-01-25 17:20:17 +01:00
An array of the data types of the function arguments. This includes
2008-07-16 03:30:23 +02:00
all arguments (including <literal>OUT</literal> and
<literal>INOUT</literal> arguments); however, if all the
arguments are <literal>IN</literal> arguments, this field will be null.
2005-03-29 21:44:23 +02:00
Note that subscripting is 1-based, whereas for historical reasons
2017-10-09 03:44:17 +02:00
<structfield>proargtypes</structfield> is subscripted from 0.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-03-29 21:44:23 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proargmodes</structfield> <type>char[]</type>
</para>
<para>
2021-01-25 17:20:17 +01:00
An array of the modes of the function arguments, encoded as
2020-05-14 05:03:39 +02:00
<literal>i</literal> for <literal>IN</literal> arguments,
<literal>o</literal> for <literal>OUT</literal> arguments,
<literal>b</literal> for <literal>INOUT</literal> arguments,
<literal>v</literal> for <literal>VARIADIC</literal> arguments,
<literal>t</literal> for <literal>TABLE</literal> arguments.
If all the arguments are <literal>IN</literal> arguments,
this field will be null.
Note that subscripts correspond to positions of
<structfield>proallargtypes</structfield> not <structfield>proargtypes</structfield>.
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2004-01-07 00:55:19 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proargnames</structfield> <type>text[]</type>
</para>
<para>
2021-01-25 17:20:17 +01:00
An array of the names of the function arguments.
2020-05-14 05:03:39 +02:00
Arguments without a name are set to empty strings in the array.
If none of the arguments have a name, this field will be null.
Note that subscripts correspond to positions of
<structfield>proallargtypes</structfield> not <structfield>proargtypes</structfield>.
</para></entry>
2004-01-07 00:55:19 +01:00
</row>
2008-12-18 19:20:35 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proargdefaults</structfield> <type>pg_node_tree</type>
</para>
<para>
2008-12-18 19:20:35 +01:00
Expression trees (in <function>nodeToString()</function> representation)
for default values. This is a list with
2017-10-09 03:44:17 +02:00
<structfield>pronargdefaults</structfield> elements, corresponding to the last
<replaceable>N</replaceable> <emphasis>input</emphasis> arguments (i.e., the last
<replaceable>N</replaceable> <structfield>proargtypes</structfield> positions).
2010-08-17 06:37:21 +02:00
If none of the arguments have defaults, this field will be null.
2020-05-14 05:03:39 +02:00
</para></entry>
2008-12-18 19:20:35 +01:00
</row>
2015-04-26 16:33:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>protrftypes</structfield> <type>oid[]</type>
2021-01-25 17:20:17 +01:00
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
2020-05-14 05:03:39 +02:00
</para>
<para>
2021-01-25 17:20:17 +01:00
An array of the argument/result data type(s) for which to apply
transforms (from the function's <literal>TRANSFORM</literal>
clause). Null if none.
2020-05-14 05:03:39 +02:00
</para></entry>
2015-04-26 16:33:14 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prosrc</structfield> <type>text</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
This tells the function handler how to invoke the function. It
might be the actual source code of the function for interpreted
languages, a link symbol, a file name, or just about anything
2010-08-17 06:37:21 +02:00
else, depending on the implementation language/call convention.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>probin</structfield> <type>text</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
Additional information about how to invoke the function.
2010-08-17 06:37:21 +02:00
Again, the interpretation is language-specific.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2021-04-07 21:30:08 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prosqlbody</structfield> <type>pg_node_tree</type>
</para>
<para>
2021-04-15 23:17:20 +02:00
Pre-parsed SQL function body. This is used for SQL-language
functions when the body is given in SQL-standard notation
rather than as a string literal. It's null in other cases.
2021-04-07 21:30:08 +02:00
</para></entry>
</row>
2002-02-19 00:11:58 +01:00
2007-09-03 02:39:26 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proconfig</structfield> <type>text[]</type>
</para>
<para>
Function's local settings for run-time configuration variables
</para></entry>
2007-09-03 02:39:26 +02:00
</row>
2002-02-19 00:11:58 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>proacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2002-02-19 00:11:58 +01:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
2001-10-16 00:47:47 +02:00
<para>
2005-01-06 00:42:03 +01:00
For compiled functions, both built-in and dynamically loaded,
2003-04-15 15:23:35 +02:00
<structfield>prosrc</structfield> contains the function's C-language
2021-04-15 23:17:20 +02:00
name (link symbol).
For SQL-language functions, <structfield>prosrc</structfield> contains
the function's source text if that is specified as a string literal;
but if the function body is specified in SQL-standard style,
<structfield>prosrc</structfield> is unused (typically it's an empty
string) and <structfield>prosqlbody</structfield> contains the
pre-parsed definition.
For all other currently-known language types,
2003-04-15 15:23:35 +02:00
<structfield>prosrc</structfield> contains the function's source
2021-04-15 23:17:20 +02:00
text. <structfield>probin</structfield> is null except for
2003-04-15 15:23:35 +02:00
dynamically-loaded C functions, for which it gives the name of the
shared library file containing the function.
2001-10-16 00:47:47 +02:00
</para>
2001-11-09 00:44:01 +01:00
</sect1>
2000-11-29 21:15:59 +01:00
2017-01-19 18:00:00 +01:00
<sect1 id="catalog-pg-publication">
<title><structname>pg_publication</structname></title>
<indexterm zone="catalog-pg-publication">
<primary>pg_publication</primary>
</indexterm>
<para>
The catalog <structname>pg_publication</structname> contains all
publications created in the database. For more on publications see
2017-11-23 15:39:47 +01:00
<xref linkend="logical-replication-publication"/>.
2017-01-19 18:00:00 +01:00
</para>
<table>
<title><structname>pg_publication</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2017-01-19 18:00:00 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubname</structfield> <type>name</type>
</para>
<para>
Name of the publication
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the publication
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>puballtables</structfield> <type>bool</type>
</para>
<para>
If true, this publication automatically includes all tables
2017-01-19 18:00:00 +01:00
in the database, including any that will be created in the future.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubinsert</structfield> <type>bool</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-insert"/> operations are replicated for
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubupdate</structfield> <type>bool</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-update"/> operations are replicated for
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubdelete</structfield> <type>bool</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-delete"/> operations are replicated for
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
2018-04-07 17:24:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubtruncate</structfield> <type>bool</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-truncate"/> operations are replicated for
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
2018-04-07 17:24:53 +02:00
</row>
2020-04-08 09:59:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pubviaroot</structfield> <type>bool</type>
</para>
<para>
If true, operations on a leaf partition are replicated using the
2020-04-08 09:59:27 +02:00
identity and schema of its topmost partitioned ancestor mentioned in the
publication instead of its own.
2020-05-14 05:03:39 +02:00
</para></entry>
2020-04-08 09:59:27 +02:00
</row>
2017-01-19 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
Allow publishing the tables of schema.
A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows
one or more schemas to be specified, whose tables are selected by the
publisher for sending the data to the subscriber.
The new syntax allows specifying both the tables and schemas. For example:
CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
OR
ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2;
A new system table "pg_publication_namespace" has been added, to maintain
the schemas that the user wants to publish through the publication.
Modified the output plugin (pgoutput) to publish the changes if the
relation is part of schema publication.
Updates pg_dump to identify and dump schema publications. Updates the \d
family of commands to display schema publications and \dRp+ variant will
now display associated schemas if any.
Author: Vignesh C, Hou Zhijie, Amit Kapila
Syntax-Suggested-by: Tom Lane, Alvaro Herrera
Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger
Tested-by: Haiying Tang
Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
<sect1 id="catalog-pg-publication-namespace">
<title><structname>pg_publication_namespace</structname></title>
<indexterm zone="catalog-pg-publication-namespace">
<primary>pg_publication_namespace</primary>
</indexterm>
<para>
The catalog <structname>pg_publication_namespace</structname> contains the
mapping between schemas and publications in the database. This is a
many-to-many mapping.
</para>
<table>
<title><structname>pg_publication_namespace</structname> Columns</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pnpubid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-publication"><structname>pg_publication</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to publication
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pnnspid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to schema
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
2017-01-19 18:00:00 +01:00
<sect1 id="catalog-pg-publication-rel">
<title><structname>pg_publication_rel</structname></title>
<indexterm zone="catalog-pg-publication-rel">
<primary>pg_publication_rel</primary>
</indexterm>
<para>
The catalog <structname>pg_publication_rel</structname> contains the
mapping between relations and publications in the database. This is a
2017-11-23 15:39:47 +01:00
many-to-many mapping. See also <xref linkend="view-pg-publication-tables"/>
2017-01-19 18:00:00 +01:00
for a more user-friendly view of this information.
</para>
<table>
<title><structname>pg_publication_rel</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2017-01-19 18:00:00 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
</thead>
<tbody>
2020-05-10 01:09:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2020-05-10 01:09:44 +02:00
</row>
2017-01-19 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prpubid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-publication"><structname>pg_publication</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to publication
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to relation
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prqual</structfield> <type>pg_node_tree</type>
</para>
<para>Expression tree (in <function>nodeToString()</function>
representation) for the relation's publication qualifying condition. Null
if there is no publication qualifying condition.</para></entry>
</row>
2022-03-26 19:06:10 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prattrs</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
This is an array of values that indicates which table columns are
part of the publication. For example, a value of <literal>1 3</literal>
would mean that the first and the third table columns are published.
A null value indicates that all columns are published.
</para></entry>
</row>
2017-01-19 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
2011-11-03 12:16:28 +01:00
<sect1 id="catalog-pg-range">
<title><structname>pg_range</structname></title>
<indexterm zone="catalog-pg-range">
<primary>pg_range</primary>
</indexterm>
<para>
2011-11-19 00:23:55 +01:00
The catalog <structname>pg_range</structname> stores information about
range types. This is in addition to the types' entries in
<link linkend="catalog-pg-type"><structname>pg_type</structname></link>.
2011-11-03 12:16:28 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_range</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2011-11-03 12:16:28 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngtypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the range type
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngsubtype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the element type (subtype) of this range type
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
Multirange datatypes
Multiranges are basically sorted arrays of non-overlapping ranges with
set-theoretic operations defined over them.
Since v14, each range type automatically gets a corresponding multirange
datatype. There are both manual and automatic mechanisms for naming multirange
types. Once can specify multirange type name using multirange_type_name
attribute in CREATE TYPE. Otherwise, a multirange type name is generated
automatically. If the range type name contains "range" then we change that to
"multirange". Otherwise, we add "_multirange" to the end.
Implementation of multiranges comes with a space-efficient internal
representation format, which evades extra paddings and duplicated storage of
oids. Altogether this format allows fetching a particular range by its index
in O(n).
Statistic gathering and selectivity estimation are implemented for multiranges.
For this purpose, stored multirange is approximated as union range without gaps.
This field will likely need improvements in the future.
Catversion is bumped.
Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com
Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0
Author: Paul Jungwirth, revised by me
Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule
Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston
Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngmultitypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the multirange type for this range type
</para></entry>
</row>
2011-11-03 12:16:28 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngcollation</structfield> <type>oid</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
OID of the collation used for range comparisons, or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngsubopc</structfield> <type>oid</type>
(references <link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the subtype's operator class used for range comparisons
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngcanonical</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the function to convert a range value into canonical form,
2021-02-02 22:15:29 +01:00
or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngsubdiff</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the function to return the difference between two element
2021-02-02 22:15:29 +01:00
values as <type>double precision</type>, or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2011-11-03 12:16:28 +01:00
</row>
</tbody>
</tgroup>
</table>
2011-11-19 00:23:55 +01:00
<para>
2017-10-09 03:44:17 +02:00
<structfield>rngsubopc</structfield> (plus <structfield>rngcollation</structfield>, if the
2011-11-19 00:23:55 +01:00
element type is collatable) determines the sort ordering used by the range
2017-10-09 03:44:17 +02:00
type. <structfield>rngcanonical</structfield> is used when the element type is
discrete. <structfield>rngsubdiff</structfield> is optional but should be supplied to
2011-11-19 00:23:55 +01:00
improve performance of GiST indexes on the range type.
</para>
2011-11-03 12:16:28 +01:00
</sect1>
2016-05-05 18:33:12 +02:00
<sect1 id="catalog-pg-replication-origin">
<title><structname>pg_replication_origin</structname></title>
<indexterm zone="catalog-pg-replication-origin">
<primary>pg_replication_origin</primary>
</indexterm>
<para>
The <structname>pg_replication_origin</structname> catalog contains
all replication origins created. For more on replication origins
2017-11-23 15:39:47 +01:00
see <xref linkend="replication-origins"/>.
2016-05-05 18:33:12 +02:00
</para>
2018-04-28 17:46:15 +02:00
<para>
Unlike most system catalogs, <structname>pg_replication_origin</structname>
is shared across all databases of a cluster: there is only one copy
of <structname>pg_replication_origin</structname> per cluster, not one per
database.
</para>
2016-05-05 18:33:12 +02:00
<table>
<title><structname>pg_replication_origin</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2016-05-05 18:33:12 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2016-05-05 18:33:12 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>roident</structfield> <type>oid</type>
</para>
<para>
A unique, cluster-wide identifier for the replication
origin. Should never leave the system.
</para></entry>
2016-05-05 18:33:12 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>roname</structfield> <type>text</type>
</para>
<para>
The external, user defined, name of a replication
origin.
</para></entry>
2016-05-05 18:33:12 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-rewrite">
2003-04-15 15:23:35 +02:00
<title><structname>pg_rewrite</structname></title>
<indexterm zone="catalog-pg-rewrite">
<primary>pg_rewrite</primary>
</indexterm>
2001-10-16 00:47:47 +02:00
<para>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_rewrite</structname> stores rewrite rules for tables and views.
2001-10-16 00:47:47 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_rewrite</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2001-10-16 00:47:47 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2001-10-16 00:47:47 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rulename</structfield> <type>name</type>
</para>
<para>
Rule name
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ev_class</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table this rule is for
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
2002-09-24 23:26:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ev_type</structfield> <type>char</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
Event type that the rule is for: 1 = <xref linkend="sql-select"/>, 2 =
<xref linkend="sql-update"/>, 3 = <xref linkend="sql-insert"/>, 4 =
<xref linkend="sql-delete"/>
2020-05-14 05:03:39 +02:00
</para></entry>
2002-09-24 23:26:44 +02:00
</row>
2007-03-20 00:38:32 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ev_enabled</structfield> <type>char</type>
</para>
<para>
2017-11-23 15:39:47 +01:00
Controls in which <xref linkend="guc-session-replication-role"/> modes
2007-03-22 16:46:56 +01:00
the rule fires.
2017-10-09 03:44:17 +02:00
<literal>O</literal> = rule fires in <quote>origin</quote> and <quote>local</quote> modes,
<literal>D</literal> = rule is disabled,
<literal>R</literal> = rule fires in <quote>replica</quote> mode,
<literal>A</literal> = rule fires always.
2020-05-14 05:03:39 +02:00
</para></entry>
2007-03-20 00:38:32 +01:00
</row>
2001-10-16 00:47:47 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>is_instead</structfield> <type>bool</type>
</para>
<para>
True if the rule is an <literal>INSTEAD</literal> rule
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ev_qual</structfield> <type>pg_node_tree</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
Expression tree (in the form of a
<function>nodeToString()</function> representation) for the
rule's qualifying condition
2020-05-14 05:03:39 +02:00
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ev_action</structfield> <type>pg_node_tree</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
Query tree (in the form of a
<function>nodeToString()</function> representation) for the
rule's action
2020-05-14 05:03:39 +02:00
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
</tbody>
</tgroup>
</table>
<note>
<para>
2003-04-15 15:23:35 +02:00
<literal>pg_class.relhasrules</literal>
2001-10-16 00:47:47 +02:00
must be true if a table has any rules in this catalog.
</para>
</note>
2001-11-09 00:44:01 +01:00
</sect1>
2001-10-16 00:47:47 +02:00
2010-09-28 02:55:27 +02:00
<sect1 id="catalog-pg-seclabel">
<title><structname>pg_seclabel</structname></title>
<indexterm zone="catalog-pg-seclabel">
<primary>pg_seclabel</primary>
</indexterm>
<para>
The catalog <structname>pg_seclabel</structname> stores security
2011-07-20 15:12:42 +02:00
labels on database objects. Security labels can be manipulated
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
with the <link linkend="sql-security-label"><command>SECURITY LABEL</command></link> command. For an easier
2017-11-23 15:39:47 +01:00
way to view security labels, see <xref linkend="view-pg-seclabels"/>.
2010-09-28 02:55:27 +02:00
</para>
2011-07-20 19:18:24 +02:00
<para>
See also <link linkend="catalog-pg-shseclabel"><structname>pg_shseclabel</structname></link>,
which performs a similar function for security labels of database objects
that are shared across a database cluster.
</para>
2010-09-28 02:55:27 +02:00
<table>
<title><structname>pg_seclabel</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2010-09-28 02:55:27 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objoid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the object this security label pertains to
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog this object appears in
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objsubid</structfield> <type>int4</type>
</para>
<para>
2010-09-28 02:55:27 +02:00
For a security label on a table column, this is the column number (the
2017-10-09 03:44:17 +02:00
<structfield>objoid</structfield> and <structfield>classoid</structfield> refer to
2010-09-28 02:55:27 +02:00
the table itself). For all other object types, this column is
zero.
2020-05-14 05:03:39 +02:00
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>provider</structfield> <type>text</type>
</para>
<para>
The label provider associated with this label.
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>label</structfield> <type>text</type>
</para>
<para>
The security label applied to this object.
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2016-12-20 18:00:00 +01:00
<sect1 id="catalog-pg-sequence">
<title><structname>pg_sequence</structname></title>
<indexterm zone="catalog-pg-sequence">
<primary>pg_sequence</primary>
</indexterm>
<para>
The catalog <structname>pg_sequence</structname> contains information about
sequences. Some of the information about sequences, such as the name and
2020-09-03 13:15:53 +02:00
the schema, is in
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>
2016-12-20 18:00:00 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_sequence</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2016-12-20 18:00:00 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry for this sequence
2020-05-14 05:03:39 +02:00
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
2016-12-21 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqtypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type of the sequence
</para></entry>
2016-12-21 18:00:00 +01:00
</row>
2016-12-20 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqstart</structfield> <type>int8</type>
</para>
<para>
Start value of the sequence
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqincrement</structfield> <type>int8</type>
</para>
<para>
Increment value of the sequence
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqmax</structfield> <type>int8</type>
</para>
<para>
Maximum value of the sequence
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqmin</structfield> <type>int8</type>
</para>
<para>
Minimum value of the sequence
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqcache</structfield> <type>int8</type>
</para>
<para>
Cache size of the sequence
</para></entry>
2016-12-20 18:00:00 +01:00
</row>
2017-02-10 21:12:32 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqcycle</structfield> <type>bool</type>
</para>
<para>
Whether the sequence cycles
</para></entry>
2017-02-10 21:12:32 +01:00
</row>
2016-12-20 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
2005-07-07 22:40:02 +02:00
<sect1 id="catalog-pg-shdepend">
<title><structname>pg_shdepend</structname></title>
<indexterm zone="catalog-pg-shdepend">
<primary>pg_shdepend</primary>
</indexterm>
<para>
The catalog <structname>pg_shdepend</structname> records the
dependency relationships between database objects and shared objects,
such as roles. This information allows
<productname>PostgreSQL</productname> to ensure that those objects are
unreferenced before attempting to delete them.
</para>
<para>
See also <link linkend="catalog-pg-depend"><structname>pg_depend</structname></link>,
which performs a similar function for dependencies involving objects
within a single database.
</para>
<para>
Unlike most system catalogs, <structname>pg_shdepend</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_shdepend</structname> per cluster, not
one per database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_shdepend</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2005-07-07 22:40:02 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dbid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the database the dependent object is in,
or zero for a shared object
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-07-15 17:41:47 +02:00
The OID of the system catalog the dependent object is in
2020-05-14 05:03:39 +02:00
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
2021-07-15 17:41:47 +02:00
The OID of the specific dependent object
2020-05-14 05:03:39 +02:00
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
2009-01-22 21:16:10 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objsubid</structfield> <type>int4</type>
</para>
<para>
2009-01-22 21:16:10 +01:00
For a table column, this is the column number (the
2017-10-09 03:44:17 +02:00
<structfield>objid</structfield> and <structfield>classid</structfield> refer to the
2010-08-17 06:37:21 +02:00
table itself). For all other object types, this column is zero.
2020-05-14 05:03:39 +02:00
</para></entry>
2009-01-22 21:16:10 +01:00
</row>
2005-07-07 22:40:02 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>refclassid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog the referenced object is in
(must be a shared catalog)
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>refobjid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the specific referenced object
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>deptype</structfield> <type>char</type>
</para>
<para>
2006-01-16 19:15:31 +01:00
A code defining the specific semantics of this dependency relationship; see text
2020-05-14 05:03:39 +02:00
</para></entry>
2005-07-07 22:40:02 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
In all cases, a <structname>pg_shdepend</structname> entry indicates that
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
the referenced object cannot be dropped without also dropping the dependent
2005-07-07 22:40:02 +02:00
object. However, there are several subflavors identified by
2017-10-09 03:44:17 +02:00
<structfield>deptype</structfield>:
2005-07-07 22:40:02 +02:00
<variablelist>
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_OWNER</symbol> (<literal>o</literal>)</term>
2005-07-07 22:40:02 +02:00
<listitem>
<para>
The referenced object (which must be a role) is the owner of the
dependent object.
</para>
</listitem>
</varlistentry>
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_ACL</symbol> (<literal>a</literal>)</term>
2005-07-07 22:40:02 +02:00
<listitem>
<para>
The referenced object (which must be a role) is mentioned in the
ACL (access control list, i.e., privileges list) of the
2017-10-09 03:44:17 +02:00
dependent object. (A <symbol>SHARED_DEPENDENCY_ACL</symbol> entry is
2005-07-07 22:40:02 +02:00
not made for the owner of the object, since the owner will have
2017-10-09 03:44:17 +02:00
a <symbol>SHARED_DEPENDENCY_OWNER</symbol> entry anyway.)
2005-07-07 22:40:02 +02:00
</para>
</listitem>
</varlistentry>
2015-07-29 01:01:53 +02:00
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_POLICY</symbol> (<literal>r</literal>)</term>
2015-07-29 01:01:53 +02:00
<listitem>
<para>
The referenced object (which must be a role) is mentioned as the
target of a dependent policy object.
</para>
</listitem>
</varlistentry>
Prevent drop of tablespaces used by partitioned relations
When a tablespace is used in a partitioned relation (per commits
ca4103025dfe in pg12 for tables and 33e6c34c3267 in pg11 for indexes),
it is possible to drop the tablespace, potentially causing various
problems. One such was reported in bug #16577, where a rewriting ALTER
TABLE causes a server crash.
Protect against this by using pg_shdepend to keep track of tablespaces
when used for relations that don't keep physical files; we now abort a
tablespace if we see that the tablespace is referenced from any
partitioned relations.
Backpatch this to 11, where this problem has been latent all along. We
don't try to create pg_shdepend entries for existing partitioned
indexes/tables, but any ones that are modified going forward will be
protected.
Note slight behavior change: when trying to drop a tablespace that
contains both regular tables as well as partitioned ones, you'd
previously get ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE and now you'll
get ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST. Arguably, the latter is more
correct.
It is possible to add protecting pg_shdepend entries for existing
tables/indexes, by doing
ALTER TABLE ONLY some_partitioned_table SET TABLESPACE pg_default;
ALTER TABLE ONLY some_partitioned_table SET TABLESPACE original_tablespace;
for each partitioned table/index that is not in the database default
tablespace. Because these partitioned objects do not have storage, no
file needs to be actually moved, so it shouldn't take more time than
what's required to acquire locks.
This query can be used to search for such relations:
SELECT ... FROM pg_class WHERE relkind IN ('p', 'I') AND reltablespace <> 0
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/16577-881633a9f9894fd5@postgresql.org
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
2021-01-14 19:32:14 +01:00
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_TABLESPACE</symbol> (<literal>t</literal>)</term>
<listitem>
<para>
The referenced object (which must be a tablespace) is mentioned as
the tablespace for a relation that doesn't have storage.
</para>
</listitem>
</varlistentry>
2005-07-07 22:40:02 +02:00
</variablelist>
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Other dependency flavors might be needed in future. Note in particular
Prevent drop of tablespaces used by partitioned relations
When a tablespace is used in a partitioned relation (per commits
ca4103025dfe in pg12 for tables and 33e6c34c3267 in pg11 for indexes),
it is possible to drop the tablespace, potentially causing various
problems. One such was reported in bug #16577, where a rewriting ALTER
TABLE causes a server crash.
Protect against this by using pg_shdepend to keep track of tablespaces
when used for relations that don't keep physical files; we now abort a
tablespace if we see that the tablespace is referenced from any
partitioned relations.
Backpatch this to 11, where this problem has been latent all along. We
don't try to create pg_shdepend entries for existing partitioned
indexes/tables, but any ones that are modified going forward will be
protected.
Note slight behavior change: when trying to drop a tablespace that
contains both regular tables as well as partitioned ones, you'd
previously get ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE and now you'll
get ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST. Arguably, the latter is more
correct.
It is possible to add protecting pg_shdepend entries for existing
tables/indexes, by doing
ALTER TABLE ONLY some_partitioned_table SET TABLESPACE pg_default;
ALTER TABLE ONLY some_partitioned_table SET TABLESPACE original_tablespace;
for each partitioned table/index that is not in the database default
tablespace. Because these partitioned objects do not have storage, no
file needs to be actually moved, so it shouldn't take more time than
what's required to acquire locks.
This query can be used to search for such relations:
SELECT ... FROM pg_class WHERE relkind IN ('p', 'I') AND reltablespace <> 0
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/16577-881633a9f9894fd5@postgresql.org
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
2021-01-14 19:32:14 +01:00
that the current definition only supports roles and tablespaces as referenced
objects.
2005-07-07 22:40:02 +02:00
</para>
2021-07-15 17:41:47 +02:00
<para>
As in the <structname>pg_depend</structname> catalog, most objects
created during <application>initdb</application> are
considered <quote>pinned</quote>. No entries are made
in <structname>pg_shdepend</structname> that would have a pinned
object as either referenced or dependent object.
</para>
2005-07-07 22:40:02 +02:00
</sect1>
2006-02-12 04:22:21 +01:00
<sect1 id="catalog-pg-shdescription">
<title><structname>pg_shdescription</structname></title>
<indexterm zone="catalog-pg-shdescription">
<primary>pg_shdescription</primary>
</indexterm>
<para>
The catalog <structname>pg_shdescription</structname> stores optional
2006-11-12 07:25:37 +01:00
descriptions (comments) for shared database objects. Descriptions can be
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
manipulated with the <link linkend="sql-comment"><command>COMMENT</command></link> command and viewed with
2006-11-12 07:25:37 +01:00
<application>psql</application>'s <literal>\d</literal> commands.
2006-02-12 04:22:21 +01:00
</para>
<para>
See also <link linkend="catalog-pg-description"><structname>pg_description</structname></link>,
which performs a similar function for descriptions involving objects
within a single database.
</para>
<para>
Unlike most system catalogs, <structname>pg_shdescription</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_shdescription</structname> per cluster, not
one per database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_shdescription</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2006-02-12 04:22:21 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2006-02-12 04:22:21 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objoid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the object this description pertains to
</para></entry>
2006-02-12 04:22:21 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog this object appears in
</para></entry>
2006-02-12 04:22:21 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>description</structfield> <type>text</type>
</para>
<para>
Arbitrary text that serves as the description of this object
</para></entry>
2006-02-12 04:22:21 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2011-07-20 19:18:24 +02:00
<sect1 id="catalog-pg-shseclabel">
<title><structname>pg_shseclabel</structname></title>
<indexterm zone="catalog-pg-shseclabel">
<primary>pg_shseclabel</primary>
</indexterm>
<para>
The catalog <structname>pg_shseclabel</structname> stores security
2012-04-12 16:43:39 +02:00
labels on shared database objects. Security labels can be manipulated
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
with the <link linkend="sql-security-label"><command>SECURITY LABEL</command></link> command. For an easier
2017-11-23 15:39:47 +01:00
way to view security labels, see <xref linkend="view-pg-seclabels"/>.
2011-07-20 19:18:24 +02:00
</para>
<para>
See also <link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link>,
which performs a similar function for security labels involving objects
within a single database.
</para>
<para>
Unlike most system catalogs, <structname>pg_shseclabel</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_shseclabel</structname> per cluster, not
one per database.
</para>
<table>
<title><structname>pg_shseclabel</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2011-07-20 19:18:24 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2011-07-20 19:18:24 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2011-07-20 19:18:24 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objoid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the object this security label pertains to
</para></entry>
2011-07-20 19:18:24 +02:00
</row>
2020-05-14 05:03:39 +02:00
2011-07-20 19:18:24 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>classoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the system catalog this object appears in
</para></entry>
2011-07-20 19:18:24 +02:00
</row>
2020-05-14 05:03:39 +02:00
2011-07-20 19:18:24 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>provider</structfield> <type>text</type>
</para>
<para>
The label provider associated with this label.
</para></entry>
2011-07-20 19:18:24 +02:00
</row>
2020-05-14 05:03:39 +02:00
2011-07-20 19:18:24 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>label</structfield> <type>text</type>
</para>
<para>
The security label applied to this object.
</para></entry>
2011-07-20 19:18:24 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2005-07-07 22:40:02 +02:00
2005-06-28 07:09:14 +02:00
<sect1 id="catalog-pg-statistic">
<title><structname>pg_statistic</structname></title>
2003-04-15 15:23:35 +02:00
2005-06-28 07:09:14 +02:00
<indexterm zone="catalog-pg-statistic">
<primary>pg_statistic</primary>
2003-04-15 15:23:35 +02:00
</indexterm>
2000-11-29 21:15:59 +01:00
<para>
2007-05-15 21:13:55 +02:00
The catalog <structname>pg_statistic</structname> stores
statistical data about the contents of the database. Entries are
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
created by <link linkend="sql-analyze"><command>ANALYZE</command></link>
2009-12-29 21:11:45 +01:00
and subsequently used by the query planner. Note that all the
2007-05-15 21:13:55 +02:00
statistical data is inherently approximate, even assuming that it
is up-to-date.
2000-11-29 21:15:59 +01:00
</para>
2009-12-29 21:11:45 +01:00
<para>
2017-10-09 03:44:17 +02:00
Normally there is one entry, with <structfield>stainherit</structfield> =
<literal>false</literal>, for each table column that has been analyzed.
2022-07-28 18:21:56 +02:00
If the table has inheritance children or partitions, a second entry with
2017-10-09 03:44:17 +02:00
<structfield>stainherit</structfield> = <literal>true</literal> is also created. This row
2009-12-29 21:11:45 +01:00
represents the column's statistics over the inheritance tree, i.e.,
statistics for the data you'd see with
2017-10-09 03:44:17 +02:00
<literal>SELECT <replaceable>column</replaceable> FROM <replaceable>table</replaceable>*</literal>,
whereas the <structfield>stainherit</structfield> = <literal>false</literal> row represents
2009-12-29 21:11:45 +01:00
the results of
2017-10-09 03:44:17 +02:00
<literal>SELECT <replaceable>column</replaceable> FROM ONLY <replaceable>table</replaceable></literal>.
2009-12-29 21:11:45 +01:00
</para>
2000-11-29 21:15:59 +01:00
<para>
2005-06-28 07:09:14 +02:00
<structname>pg_statistic</structname> also stores statistical data about
the values of index expressions. These are described as if they were
actual data columns; in particular, <structfield>starelid</structfield>
references the index. No entry is made for an ordinary non-expression
index column, however, since it would be redundant with the entry
2009-12-29 21:11:45 +01:00
for the underlying table column. Currently, entries for index expressions
2017-10-09 03:44:17 +02:00
always have <structfield>stainherit</structfield> = <literal>false</literal>.
2000-11-29 21:15:59 +01:00
</para>
2001-10-16 00:47:47 +02:00
<para>
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Since different kinds of statistics might be appropriate for different
2005-06-28 07:09:14 +02:00
kinds of data, <structname>pg_statistic</structname> is designed not
to assume very much about what sort of statistics it stores. Only
extremely general statistics (such as nullness) are given dedicated
columns in <structname>pg_statistic</structname>. Everything else
is stored in <quote>slots</quote>, which are groups of associated columns
whose content is identified by a code number in one of the slot's columns.
For more information see
<filename>src/include/catalog/pg_statistic.h</filename>.
2001-05-07 02:43:27 +02:00
</para>
2001-10-16 00:47:47 +02:00
<para>
<structname>pg_statistic</structname> should not be readable by the
public, since even statistical information about a table's contents
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
might be considered sensitive. (Example: minimum and maximum values
2001-10-16 00:47:47 +02:00
of a salary column might be quite interesting.)
2003-10-18 00:38:20 +02:00
<link linkend="view-pg-stats"><structname>pg_stats</structname></link>
is a publicly readable view on
2001-10-16 00:47:47 +02:00
<structname>pg_statistic</structname> that only exposes information
about those tables that are readable by the current user.
</para>
2001-05-07 02:43:27 +02:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_statistic</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2001-05-07 02:43:27 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>starelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table or index that the described column belongs to
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>staattnum</structfield> <type>int2</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
The number of the described column
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
2009-12-29 21:11:45 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stainherit</structfield> <type>bool</type>
</para>
<para>
2022-07-28 18:21:56 +02:00
If true, the stats include values from child tables, not just the
2020-05-14 05:03:39 +02:00
values in the specified relation
</para></entry>
2009-12-29 21:11:45 +01:00
</row>
2001-05-07 02:43:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stanullfrac</structfield> <type>float4</type>
</para>
<para>
The fraction of the column's entries that are null
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stawidth</structfield> <type>int4</type>
</para>
<para>
The average stored width, in bytes, of nonnull entries
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stadistinct</structfield> <type>float4</type>
</para>
<para>
The number of distinct nonnull data values in the column.
A value greater than zero is the actual number of distinct values.
A value less than zero is the negative of a multiplier for the number
of rows in the table; for example, a column in which about 80% of the
values are nonnull and each nonnull value appears about twice on
average could be represented by <structfield>stadistinct</structfield> = -0.4.
A zero value means the number of distinct values is unknown.
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stakind<replaceable>N</replaceable></structfield> <type>int2</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
A code number indicating the kind of statistics stored in the
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote> of the
2010-08-17 06:37:21 +02:00
<structname>pg_statistic</structname> row.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>staop<replaceable>N</replaceable></structfield> <type>oid</type>
(references <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2003-04-15 15:23:35 +02:00
An operator used to derive the statistics stored in the
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote>. For example, a
2003-04-15 15:23:35 +02:00
histogram slot would show the <literal><</literal> operator
2010-08-17 06:37:21 +02:00
that defines the sort order of the data.
2021-02-02 22:15:29 +01:00
Zero if the statistics kind does not require an operator.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
Make pg_statistic and related code account more honestly for collations.
When we first put in collations support, we basically punted on teaching
pg_statistic, ANALYZE, and the planner selectivity functions about that.
They've just used DEFAULT_COLLATION_OID independently of the actual
collation of the data. It's time to improve that, so:
* Add columns to pg_statistic that record the specific collation associated
with each statistics slot.
* Teach ANALYZE to use the column's actual collation when comparing values
for statistical purposes, and record this in the appropriate slot. (Note
that type-specific typanalyze functions are now expected to fill
stats->stacoll with the appropriate collation, too.)
* Teach assorted selectivity functions to use the actual collation of
the stats they are looking at, instead of just assuming it's
DEFAULT_COLLATION_OID.
This should give noticeably better results in selectivity estimates for
columns with nondefault collations, at least for query clauses that use
that same collation (which would be the default behavior in most cases).
It's still true that comparisons with explicit COLLATE clauses different
from the stored data's collation won't be well-estimated, but that's no
worse than before. Also, this patch does make the first step towards
doing better with that, which is that it's now theoretically possible to
collect stats for a collation other than the column's own collation.
Patch by me; thanks to Peter Eisentraut for review.
Discussion: https://postgr.es/m/14706.1544630227@sss.pgh.pa.us
2018-12-14 18:52:49 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stacoll<replaceable>N</replaceable></structfield> <type>oid</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Make pg_statistic and related code account more honestly for collations.
When we first put in collations support, we basically punted on teaching
pg_statistic, ANALYZE, and the planner selectivity functions about that.
They've just used DEFAULT_COLLATION_OID independently of the actual
collation of the data. It's time to improve that, so:
* Add columns to pg_statistic that record the specific collation associated
with each statistics slot.
* Teach ANALYZE to use the column's actual collation when comparing values
for statistical purposes, and record this in the appropriate slot. (Note
that type-specific typanalyze functions are now expected to fill
stats->stacoll with the appropriate collation, too.)
* Teach assorted selectivity functions to use the actual collation of
the stats they are looking at, instead of just assuming it's
DEFAULT_COLLATION_OID.
This should give noticeably better results in selectivity estimates for
columns with nondefault collations, at least for query clauses that use
that same collation (which would be the default behavior in most cases).
It's still true that comparisons with explicit COLLATE clauses different
from the stored data's collation won't be well-estimated, but that's no
worse than before. Also, this patch does make the first step towards
doing better with that, which is that it's now theoretically possible to
collect stats for a collation other than the column's own collation.
Patch by me; thanks to Peter Eisentraut for review.
Discussion: https://postgr.es/m/14706.1544630227@sss.pgh.pa.us
2018-12-14 18:52:49 +01:00
The collation used to derive the statistics stored in the
<replaceable>N</replaceable>th <quote>slot</quote>. For example, a
histogram slot for a collatable column would show the collation that
defines the sort order of the data. Zero for noncollatable data.
2020-05-14 05:03:39 +02:00
</para></entry>
Make pg_statistic and related code account more honestly for collations.
When we first put in collations support, we basically punted on teaching
pg_statistic, ANALYZE, and the planner selectivity functions about that.
They've just used DEFAULT_COLLATION_OID independently of the actual
collation of the data. It's time to improve that, so:
* Add columns to pg_statistic that record the specific collation associated
with each statistics slot.
* Teach ANALYZE to use the column's actual collation when comparing values
for statistical purposes, and record this in the appropriate slot. (Note
that type-specific typanalyze functions are now expected to fill
stats->stacoll with the appropriate collation, too.)
* Teach assorted selectivity functions to use the actual collation of
the stats they are looking at, instead of just assuming it's
DEFAULT_COLLATION_OID.
This should give noticeably better results in selectivity estimates for
columns with nondefault collations, at least for query clauses that use
that same collation (which would be the default behavior in most cases).
It's still true that comparisons with explicit COLLATE clauses different
from the stored data's collation won't be well-estimated, but that's no
worse than before. Also, this patch does make the first step towards
doing better with that, which is that it's now theoretically possible to
collect stats for a collation other than the column's own collation.
Patch by me; thanks to Peter Eisentraut for review.
Discussion: https://postgr.es/m/14706.1544630227@sss.pgh.pa.us
2018-12-14 18:52:49 +01:00
</row>
2001-05-07 02:43:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stanumbers<replaceable>N</replaceable></structfield> <type>float4[]</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
Numerical statistics of the appropriate kind for the
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote>, or null if the slot
2006-01-16 19:15:31 +01:00
kind does not involve numerical values
2020-05-14 05:03:39 +02:00
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stavalues<replaceable>N</replaceable></structfield> <type>anyarray</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
Column data values of the appropriate kind for the
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote>, or null if the slot
2003-04-15 15:23:35 +02:00
kind does not store any data values. Each array's element
2012-03-04 02:20:19 +01:00
values are actually of the specific column's data type, or a related
type such as an array's element type, so there is no way to define
2017-10-09 03:44:17 +02:00
these columns' type more specifically than <type>anyarray</type>.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-05-07 02:43:27 +02:00
</row>
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2001-05-07 02:43:27 +02:00
2017-05-15 01:15:52 +02:00
<sect1 id="catalog-pg-statistic-ext">
<title><structname>pg_statistic_ext</structname></title>
<indexterm zone="catalog-pg-statistic-ext">
<primary>pg_statistic_ext</primary>
</indexterm>
<para>
The catalog <structname>pg_statistic_ext</structname>
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
holds definitions of extended planner statistics.
2017-10-09 03:44:17 +02:00
Each row in this catalog corresponds to a <firstterm>statistics object</firstterm>
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
created with <link linkend="sql-createstatistics"><command>CREATE STATISTICS</command></link>.
2017-05-15 01:15:52 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_statistic_ext</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2017-05-15 01:15:52 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
</thead>
<tbody>
2020-05-10 01:09:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2020-05-10 01:09:44 +02:00
</row>
2017-05-15 01:15:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Table containing the columns described by this object
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxname</structfield> <type>name</type>
</para>
<para>
Name of the statistics object
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2017-05-15 01:15:52 +02:00
The OID of the namespace that contains this statistics object
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the statistics object
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
2024-03-17 12:22:05 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxkeys</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
An array of attribute numbers, indicating which table columns are
covered by this statistics object;
for example a value of <literal>1 3</literal> would
mean that the first and the third table columns are covered
</para></entry>
</row>
2020-03-18 16:48:12 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2023-07-03 07:09:22 +02:00
<structfield>stxstattarget</structfield> <type>int2</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
2020-03-18 16:48:12 +01:00
<structfield>stxstattarget</structfield> controls the level of detail
of statistics accumulated for this statistics object by
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-analyze"><command>ANALYZE</command></link>.
2020-03-18 16:48:12 +01:00
A zero value indicates that no statistics should be collected.
2024-03-17 12:22:05 +01:00
A null value says to use the maximum of the statistics targets of
2020-09-21 18:43:42 +02:00
the referenced columns, if set, or the system default statistics target.
2020-04-10 04:18:39 +02:00
Positive values of <structfield>stxstattarget</structfield>
2020-03-18 16:48:12 +01:00
determine the target number of <quote>most common values</quote>
to collect.
2020-05-14 05:03:39 +02:00
</para></entry>
2020-03-18 16:48:12 +01:00
</row>
2017-05-15 01:15:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxkind</structfield> <type>char[]</type>
</para>
<para>
2021-03-23 04:45:26 +01:00
An array containing codes for the enabled statistics kinds;
2020-05-14 05:03:39 +02:00
valid values are:
<literal>d</literal> for n-distinct statistics,
2021-07-15 23:22:58 +02:00
<literal>f</literal> for functional dependency statistics,
<literal>m</literal> for most common values (MCV) list statistics, and
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
<literal>e</literal> for expression statistics
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxexprs</structfield> <type>pg_node_tree</type>
</para>
<para>
Expression trees (in <function>nodeToString()</function>
representation) for statistics object attributes that are not simple
column references. This is a list with one element per expression.
Null if all statistics object attributes are simple references.
</para></entry>
</row>
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</tbody>
</tgroup>
</table>
<para>
2019-10-06 20:14:45 +02:00
The <structname>pg_statistic_ext</structname> entry is filled in
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
completely during <link linkend="sql-createstatistics"><command>CREATE STATISTICS</command></link>, but the actual
2019-10-06 20:14:45 +02:00
statistical values are not computed then.
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
Subsequent <link linkend="sql-analyze"><command>ANALYZE</command></link> commands compute the desired values
2019-10-06 20:14:45 +02:00
and populate an entry in the
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
<link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link>
catalog.
</para>
</sect1>
<sect1 id="catalog-pg-statistic-ext-data">
<title><structname>pg_statistic_ext_data</structname></title>
<indexterm zone="catalog-pg-statistic-ext">
<primary>pg_statistic_ext_data</primary>
</indexterm>
<para>
The catalog <structname>pg_statistic_ext_data</structname>
2020-09-03 13:15:53 +02:00
holds data for extended planner statistics defined in
<link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
Each row in this catalog corresponds to a <firstterm>statistics object</firstterm>
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
created with <link linkend="sql-createstatistics"><command>CREATE STATISTICS</command></link>.
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</para>
Add stxdinherit flag to pg_statistic_ext_data
Add pg_statistic_ext_data.stxdinherit flag, so that for each extended
statistics definition we can store two versions of data - one for the
relation alone, one for the whole inheritance tree. This is analogous to
pg_statistic.stainherit, but we failed to include such flag in catalogs
for extended statistics, and we had to work around it (see commits
859b3003de, 36c4bc6e72 and 20b9fa308e).
This changes the relationship between the two catalogs storing extended
statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until
now, there was a simple 1:1 mapping - for each definition there was one
pg_statistic_ext_data row, and this row was inserted while creating the
statistics (and then updated during ANALYZE). With the stxdinherit flag,
we don't know how many rows there will be (child relations may be added
after the statistics object is defined), so there may be up to two rows.
We could make CREATE STATISTICS to always create both rows, but that
seems wasteful - without partitioning we only need stxdinherit=false
rows, and declaratively partitioned tables need only stxdinherit=true.
So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS,
and instead make that a responsibility of ANALYZE. Which is what we do
for regular statistics too.
Patch by me, with extensive improvements and fixes by Justin Pryzby.
Author: Tomas Vondra, Justin Pryzby
Reviewed-by: Tomas Vondra, Justin Pryzby
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
<para>
Normally there is one entry, with <structfield>stxdinherit</structfield> =
<literal>false</literal>, for each statistics object that has been analyzed.
2022-07-28 18:21:56 +02:00
If the table has inheritance children or partitions, a second entry with
Add stxdinherit flag to pg_statistic_ext_data
Add pg_statistic_ext_data.stxdinherit flag, so that for each extended
statistics definition we can store two versions of data - one for the
relation alone, one for the whole inheritance tree. This is analogous to
pg_statistic.stainherit, but we failed to include such flag in catalogs
for extended statistics, and we had to work around it (see commits
859b3003de, 36c4bc6e72 and 20b9fa308e).
This changes the relationship between the two catalogs storing extended
statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until
now, there was a simple 1:1 mapping - for each definition there was one
pg_statistic_ext_data row, and this row was inserted while creating the
statistics (and then updated during ANALYZE). With the stxdinherit flag,
we don't know how many rows there will be (child relations may be added
after the statistics object is defined), so there may be up to two rows.
We could make CREATE STATISTICS to always create both rows, but that
seems wasteful - without partitioning we only need stxdinherit=false
rows, and declaratively partitioned tables need only stxdinherit=true.
So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS,
and instead make that a responsibility of ANALYZE. Which is what we do
for regular statistics too.
Patch by me, with extensive improvements and fixes by Justin Pryzby.
Author: Tomas Vondra, Justin Pryzby
Reviewed-by: Tomas Vondra, Justin Pryzby
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
<structfield>stxdinherit</structfield> = <literal>true</literal> is also created.
This row represents the statistics object over the inheritance tree, i.e.,
statistics for the data you'd see with
<literal>SELECT * FROM <replaceable>table</replaceable>*</literal>,
whereas the <structfield>stxdinherit</structfield> = <literal>false</literal> row
represents the results of
<literal>SELECT * FROM ONLY <replaceable>table</replaceable></literal>.
</para>
2019-10-06 20:14:45 +02:00
<para>
2020-09-03 13:15:53 +02:00
Like <link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link>,
2019-10-06 20:14:45 +02:00
<structname>pg_statistic_ext_data</structname> should not be
readable by the public, since the contents might be considered sensitive.
(Example: most common combinations of values in columns might be quite
interesting.)
<link linkend="view-pg-stats-ext"><structname>pg_stats_ext</structname></link>
is a publicly readable view
on <structname>pg_statistic_ext_data</structname> (after joining
2020-09-03 13:15:53 +02:00
with <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>) that only exposes
2019-10-06 20:14:45 +02:00
information about those tables and columns that are readable by the
current user.
</para>
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
<table>
<title><structname>pg_statistic_ext_data</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
Extended statistics object containing the definition for this data
2020-05-14 05:03:39 +02:00
</para></entry>
Rework the pg_statistic_ext catalog
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</row>
Add stxdinherit flag to pg_statistic_ext_data
Add pg_statistic_ext_data.stxdinherit flag, so that for each extended
statistics definition we can store two versions of data - one for the
relation alone, one for the whole inheritance tree. This is analogous to
pg_statistic.stainherit, but we failed to include such flag in catalogs
for extended statistics, and we had to work around it (see commits
859b3003de, 36c4bc6e72 and 20b9fa308e).
This changes the relationship between the two catalogs storing extended
statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until
now, there was a simple 1:1 mapping - for each definition there was one
pg_statistic_ext_data row, and this row was inserted while creating the
statistics (and then updated during ANALYZE). With the stxdinherit flag,
we don't know how many rows there will be (child relations may be added
after the statistics object is defined), so there may be up to two rows.
We could make CREATE STATISTICS to always create both rows, but that
seems wasteful - without partitioning we only need stxdinherit=false
rows, and declaratively partitioned tables need only stxdinherit=true.
So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS,
and instead make that a responsibility of ANALYZE. Which is what we do
for regular statistics too.
Patch by me, with extensive improvements and fixes by Justin Pryzby.
Author: Tomas Vondra, Justin Pryzby
Reviewed-by: Tomas Vondra, Justin Pryzby
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxdinherit</structfield> <type>bool</type>
</para>
<para>
2022-07-28 18:21:56 +02:00
If true, the stats include values from child tables, not just the
Add stxdinherit flag to pg_statistic_ext_data
Add pg_statistic_ext_data.stxdinherit flag, so that for each extended
statistics definition we can store two versions of data - one for the
relation alone, one for the whole inheritance tree. This is analogous to
pg_statistic.stainherit, but we failed to include such flag in catalogs
for extended statistics, and we had to work around it (see commits
859b3003de, 36c4bc6e72 and 20b9fa308e).
This changes the relationship between the two catalogs storing extended
statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until
now, there was a simple 1:1 mapping - for each definition there was one
pg_statistic_ext_data row, and this row was inserted while creating the
statistics (and then updated during ANALYZE). With the stxdinherit flag,
we don't know how many rows there will be (child relations may be added
after the statistics object is defined), so there may be up to two rows.
We could make CREATE STATISTICS to always create both rows, but that
seems wasteful - without partitioning we only need stxdinherit=false
rows, and declaratively partitioned tables need only stxdinherit=true.
So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS,
and instead make that a responsibility of ANALYZE. Which is what we do
for regular statistics too.
Patch by me, with extensive improvements and fixes by Justin Pryzby.
Author: Tomas Vondra, Justin Pryzby
Reviewed-by: Tomas Vondra, Justin Pryzby
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
values in the specified relation
</para></entry>
</row>
2017-05-15 01:15:52 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxdndistinct</structfield> <type>pg_ndistinct</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
N-distinct counts, serialized as <structname>pg_ndistinct</structname> type
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxddependencies</structfield> <type>pg_dependencies</type>
</para>
<para>
2017-05-15 01:15:52 +02:00
Functional dependency statistics, serialized
2017-10-09 03:44:17 +02:00
as <structname>pg_dependencies</structname> type
2020-05-14 05:03:39 +02:00
</para></entry>
2017-05-15 01:15:52 +02:00
</row>
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxdmcv</structfield> <type>pg_mcv_list</type>
</para>
<para>
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
MCV (most-common values) list statistics, serialized as
2019-10-06 20:14:45 +02:00
<structname>pg_mcv_list</structname> type
2020-05-14 05:03:39 +02:00
</para></entry>
Add support for multivariate MCV lists
Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
</row>
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2021-05-25 00:03:47 +02:00
<structfield>stxdexpr</structfield> <type>pg_statistic[]</type>
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
</para>
<para>
2021-05-25 00:03:47 +02:00
Per-expression statistics, serialized as an array of
<structname>pg_statistic</structname> type
Extended statistics on expressions
Allow defining extended statistics on expressions, not just just on
simple column references. With this commit, expressions are supported
by all existing extended statistics kinds, improving the same types of
estimates. A simple example may look like this:
CREATE TABLE t (a int);
CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t;
ANALYZE t;
The collected statistics are useful e.g. to estimate queries with those
expressions in WHERE or GROUP BY clauses:
SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0;
SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20);
This introduces new internal statistics kind 'e' (expressions) which is
built automatically when the statistics object definition includes any
expressions. This represents single-expression statistics, as if there
was an expression index (but without the index maintenance overhead).
The statistics is stored in pg_statistics_ext_data as an array of
composite types, which is possible thanks to 79f6a942bd.
CREATE STATISTICS allows building statistics on a single expression, in
which case in which case it's not possible to specify statistics kinds.
A new system view pg_stats_ext_exprs can be used to display expression
statistics, similarly to pg_stats and pg_stats_ext views.
ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it
treats indexes, i.e. it drops and recreates the statistics. This means
all statistics are reset, and we no longer try to preserve at least the
functional dependencies. This should not be a major issue in practice,
as the functional dependencies actually rely on per-column statistics,
which were always reset anyway.
Author: Tomas Vondra
Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
</para></entry>
</row>
2017-05-15 01:15:52 +02:00
</tbody>
</tgroup>
</table>
</sect1>
2017-01-19 18:00:00 +01:00
<sect1 id="catalog-pg-subscription">
<title><structname>pg_subscription</structname></title>
<indexterm zone="catalog-pg-subscription">
<primary>pg_subscription</primary>
</indexterm>
<para>
The catalog <structname>pg_subscription</structname> contains all existing
logical replication subscriptions. For more information about logical
2017-11-23 15:39:47 +01:00
replication see <xref linkend="logical-replication"/>.
2017-01-19 18:00:00 +01:00
</para>
<para>
Unlike most system catalogs, <structname>pg_subscription</structname> is
2018-04-28 17:46:15 +02:00
shared across all databases of a cluster: there is only one copy
2017-01-19 18:00:00 +01:00
of <structname>pg_subscription</structname> per cluster, not one per
database.
</para>
<para>
2017-03-03 20:13:48 +01:00
Access to the column <structfield>subconninfo</structfield> is revoked from
normal users, because it could contain plain-text passwords.
2017-01-19 18:00:00 +01:00
</para>
<table>
<title><structname>pg_subscription</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2017-01-19 18:00:00 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subdbid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-07-18 18:44:51 +02:00
OID of the database that the subscription resides in
2020-05-14 05:03:39 +02:00
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
2022-04-07 06:09:25 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subskiplsn</structfield> <type>pg_lsn</type>
</para>
<para>
Finish LSN of the transaction whose changes are to be skipped, if a valid
LSN; otherwise <literal>0/0</literal>.
</para></entry>
</row>
2017-01-19 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subname</structfield> <type>name</type>
</para>
<para>
Name of the subscription
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the subscription
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subenabled</structfield> <type>bool</type>
</para>
<para>
2020-07-18 18:44:51 +02:00
If true, the subscription is enabled and should be replicating
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subbinary</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will request that the publisher send data
in binary format
2020-05-14 05:03:39 +02:00
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
2021-03-17 03:10:23 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Perform apply of large transactions by parallel workers.
Currently, for large transactions, the publisher sends the data in
multiple streams (changes divided into chunks depending upon
logical_decoding_work_mem), and then on the subscriber-side, the apply
worker writes the changes into temporary files and once it receives the
commit, it reads from those files and applies the entire transaction. To
improve the performance of such transactions, we can instead allow them to
be applied via parallel workers.
In this approach, we assign a new parallel apply worker (if available) as
soon as the xact's first stream is received and the leader apply worker
will send changes to this new worker via shared memory. The parallel apply
worker will directly apply the change instead of writing it to temporary
files. However, if the leader apply worker times out while attempting to
send a message to the parallel apply worker, it will switch to
"partial serialize" mode - in this mode, the leader serializes all
remaining changes to a file and notifies the parallel apply workers to
read and apply them at the end of the transaction. We use a non-blocking
way to send the messages from the leader apply worker to the parallel
apply to avoid deadlocks. We keep this parallel apply assigned till the
transaction commit is received and also wait for the worker to finish at
commit. This preserves commit ordering and avoid writing to and reading
from files in most cases. We still need to spill if there is no worker
available.
This patch also extends the SUBSCRIPTION 'streaming' parameter so that the
user can control whether to apply the streaming transaction in a parallel
apply worker or spill the change to disk. The user can set the streaming
parameter to 'on/off', or 'parallel'. The parameter value 'parallel' means
the streaming will be applied via a parallel apply worker, if available.
The parameter value 'on' means the streaming transaction will be spilled
to disk. The default value is 'off' (same as current behaviour).
In addition, the patch extends the logical replication STREAM_ABORT
message so that abort_lsn and abort_time can also be sent which can be
used to update the replication origin in parallel apply worker when the
streaming transaction is aborted. Because this message extension is needed
to support parallel streaming, parallel streaming is not supported for
publications on servers < PG16.
Author: Hou Zhijie, Wang wei, Amit Kapila with design inputs from Sawada Masahiko
Reviewed-by: Sawada Masahiko, Peter Smith, Dilip Kumar, Shi yu, Kuroda Hayato, Shveta Mallik
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-09 02:30:39 +01:00
<structfield>substream</structfield> <type>char</type>
2021-03-17 03:10:23 +01:00
</para>
<para>
Perform apply of large transactions by parallel workers.
Currently, for large transactions, the publisher sends the data in
multiple streams (changes divided into chunks depending upon
logical_decoding_work_mem), and then on the subscriber-side, the apply
worker writes the changes into temporary files and once it receives the
commit, it reads from those files and applies the entire transaction. To
improve the performance of such transactions, we can instead allow them to
be applied via parallel workers.
In this approach, we assign a new parallel apply worker (if available) as
soon as the xact's first stream is received and the leader apply worker
will send changes to this new worker via shared memory. The parallel apply
worker will directly apply the change instead of writing it to temporary
files. However, if the leader apply worker times out while attempting to
send a message to the parallel apply worker, it will switch to
"partial serialize" mode - in this mode, the leader serializes all
remaining changes to a file and notifies the parallel apply workers to
read and apply them at the end of the transaction. We use a non-blocking
way to send the messages from the leader apply worker to the parallel
apply to avoid deadlocks. We keep this parallel apply assigned till the
transaction commit is received and also wait for the worker to finish at
commit. This preserves commit ordering and avoid writing to and reading
from files in most cases. We still need to spill if there is no worker
available.
This patch also extends the SUBSCRIPTION 'streaming' parameter so that the
user can control whether to apply the streaming transaction in a parallel
apply worker or spill the change to disk. The user can set the streaming
parameter to 'on/off', or 'parallel'. The parameter value 'parallel' means
the streaming will be applied via a parallel apply worker, if available.
The parameter value 'on' means the streaming transaction will be spilled
to disk. The default value is 'off' (same as current behaviour).
In addition, the patch extends the logical replication STREAM_ABORT
message so that abort_lsn and abort_time can also be sent which can be
used to update the replication origin in parallel apply worker when the
streaming transaction is aborted. Because this message extension is needed
to support parallel streaming, parallel streaming is not supported for
publications on servers < PG16.
Author: Hou Zhijie, Wang wei, Amit Kapila with design inputs from Sawada Masahiko
Reviewed-by: Sawada Masahiko, Peter Smith, Dilip Kumar, Shi yu, Kuroda Hayato, Shveta Mallik
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-09 02:30:39 +01:00
Controls how to handle the streaming of in-progress transactions:
<literal>f</literal> = disallow streaming of in-progress transactions,
<literal>t</literal> = spill the changes of in-progress transactions to
disk and apply at once after the transaction is committed on the
publisher and received by the subscriber,
<literal>p</literal> = apply changes directly using a parallel apply
2023-10-23 02:58:55 +02:00
worker if available (same as <literal>t</literal> if no worker is
available)
2021-03-17 03:10:23 +01:00
</para></entry>
</row>
Add support for prepared transactions to built-in logical replication.
To add support for streaming transactions at prepare time into the
built-in logical replication, we need to do the following things:
* Modify the output plugin (pgoutput) to implement the new two-phase API
callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle two-phase
transactions by replaying them on prepare.
* Add a new SUBSCRIPTION option "two_phase" to allow users to enable
two-phase transactions. We enable the two_phase once the initial data sync
is over.
We however must explicitly disable replication of two-phase transactions
during replication slot creation, even if the plugin supports it. We
don't need to replicate the changes accumulated during this phase,
and moreover, we don't have a replication connection open so we don't know
where to send the data anyway.
The streaming option is not allowed with this new two_phase option. This
can be done as a separate patch.
We don't allow to toggle two_phase option of a subscription because it can
lead to an inconsistent replica. For the same reason, we don't allow to
refresh the publication once the two_phase is enabled for a subscription
unless copy_data option is false.
Author: Peter Smith, Ajin Cherian and Amit Kapila based on previous work by Nikhil Sontakke and Stas Kelvich
Reviewed-by: Amit Kapila, Sawada Masahiko, Vignesh C, Dilip Kumar, Takamichi Osumi, Greg Nancarrow
Tested-By: Haiying Tang
Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru
Discussion: https://postgr.es/m/CAA4eK1+opiV4aFTmWWUF9h_32=HfPOW9vZASHarT0UA5oBrtGw@mail.gmail.com
2021-07-14 04:03:50 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subtwophasestate</structfield> <type>char</type>
</para>
<para>
State codes for two-phase mode:
<literal>d</literal> = disabled,
<literal>p</literal> = pending enablement,
<literal>e</literal> = enabled
</para></entry>
</row>
Optionally disable subscriptions on error.
Logical replication apply workers for a subscription can easily get stuck
in an infinite loop of attempting to apply a change, triggering an error
(such as a constraint violation), exiting with the error written to the
subscription server log, and restarting.
To partially remedy the situation, this patch adds a new subscription
option named 'disable_on_error'. To be consistent with old behavior, this
option defaults to false. When true, both the tablesync worker and apply
worker catch any errors thrown and disable the subscription in order to
break the loop. The error is still also written in the logs.
Once the subscription is disabled, users can either manually resolve the
conflict/error or skip the conflicting transaction by using
pg_replication_origin_advance() function. After resolving the conflict,
users need to enable the subscription to allow apply process to proceed.
Author: Osumi Takamichi and Mark Dilger
Reviewed-by: Greg Nancarrow, Vignesh C, Amit Kapila, Wang wei, Tang Haiying, Peter Smith, Masahiko Sawada, Shi Yu
Discussion : https://postgr.es/m/DB35438F-9356-4841-89A0-412709EBD3AB%40enterprisedb.com
2022-03-14 05:02:40 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subdisableonerr</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will be disabled if one of its workers
detects an error
</para></entry>
</row>
2017-01-19 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2023-04-11 17:00:36 +02:00
<structfield>subpasswordrequired</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will be required to specify a password
for authentication
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subrunasowner</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will be run with the permissions
of the subscription owner
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Add a failover option to subscriptions.
This commit introduces a new subscription option named 'failover', which
provides users with the ability to set the failover property of the
replication slot on the publisher when creating or altering a
subscription.
This uses the replication commands introduced by commit 7329240437 to
enable the failover option for a logical replication slot.
If the failover option is set to true, the associated replication slots
(i.e. the main slot and the table sync slots) in the upstream database are
enabled to be synchronized to the standbys. Note that the capability to
sync the replication slots will be added in subsequent commits.
Thanks to Masahiko Sawada for the design inputs.
Author: Shveta Malik, Hou Zhijie, Ajin Cherian
Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
<structfield>subfailover</structfield> <type>bool</type>
</para>
<para>
If true, the associated replication slots (i.e. the main slot and the
table sync slots) in the upstream database are enabled to be
synchronized to the standbys
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
2020-05-14 05:03:39 +02:00
<structfield>subconninfo</structfield> <type>text</type>
</para>
<para>
Connection string to the upstream database
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subslotname</structfield> <type>name</type>
</para>
<para>
2020-07-18 18:44:51 +02:00
Name of the replication slot in the upstream database (also used
Correctly mark pg_subscription.subslotname as nullable.
Due to the layout of this catalog, subslotname has to be explicitly
marked BKI_FORCE_NULL, else initdb will default to the assumption
that it's non-nullable. Since, in fact, CREATE/ALTER SUBSCRIPTION
will store null values there, the existing marking is just wrong,
and has been since this catalog was invented.
We haven't noticed because not much in the system actually depends
on attnotnull being truthful. However, JIT'ed tuple deconstruction
does depend on that in some cases, allowing crashes or wrong answers
in queries that inspect pg_subscription. Commit 9de77b545 quite
accidentally exposed this on the buildfarm members that force JIT
activation.
Back-patch to v13. The problem goes further back, but we cannot
force initdb in released branches, so some klugier solution will
be needed there. Before working on that, push this simple fix
to try to get the buildfarm back to green.
Discussion: https://postgr.es/m/4118109.1595096139@sss.pgh.pa.us
2020-07-19 18:37:23 +02:00
for the local replication origin name);
null represents <literal>NONE</literal>
2020-05-14 05:03:39 +02:00
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
2020-05-10 01:09:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subsynccommit</structfield> <type>text</type>
</para>
<para>
2020-07-18 18:44:51 +02:00
The <varname>synchronous_commit</varname>
setting for the subscription's workers to use
2020-05-14 05:03:39 +02:00
</para></entry>
2020-05-10 01:09:44 +02:00
</row>
2017-01-19 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subpublications</structfield> <type>text[]</type>
</para>
<para>
2020-07-18 18:44:51 +02:00
Array of subscribed publication names. These reference
publications defined in the upstream database. For more on publications
2017-11-23 15:39:47 +01:00
see <xref linkend="logical-replication-publication"/>.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
2022-07-21 05:17:38 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>suborigin</structfield> <type>text</type>
</para>
<para>
The origin value must be either <literal>none</literal> or
<literal>any</literal>. The default is <literal>any</literal>.
If <literal>none</literal>, the subscription will request the publisher
to only send changes that don't have an origin. If
<literal>any</literal>, the publisher sends changes regardless of their
origin.
</para></entry>
</row>
2017-01-19 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
2001-05-07 02:43:27 +02:00
2017-03-23 13:36:36 +01:00
<sect1 id="catalog-pg-subscription-rel">
<title><structname>pg_subscription_rel</structname></title>
<indexterm zone="catalog-pg-subscription-rel">
<primary>pg_subscription_rel</primary>
</indexterm>
<para>
The catalog <structname>pg_subscription_rel</structname> contains the
state for each replicated relation in each subscription. This is a
many-to-many mapping.
</para>
<para>
This catalog only contains tables known to the subscription after running
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
either <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link> or
2020-09-03 13:15:53 +02:00
<link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION ... REFRESH
PUBLICATION</command></link>.
2017-03-23 13:36:36 +01:00
</para>
<table>
<title><structname>pg_subscription_rel</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2017-03-23 13:36:36 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2017-03-23 13:36:36 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srsubid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-subscription"><structname>pg_subscription</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to subscription
</para></entry>
2017-03-23 13:36:36 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to relation
</para></entry>
2017-03-23 13:36:36 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srsubstate</structfield> <type>char</type>
</para>
<para>
2017-03-23 13:36:36 +01:00
State code:
2017-10-09 03:44:17 +02:00
<literal>i</literal> = initialize,
<literal>d</literal> = data is being copied,
Allow multiple xacts during table sync in logical replication.
For the initial table data synchronization in logical replication, we use
a single transaction to copy the entire table and then synchronize the
position in the stream with the main apply worker.
There are multiple downsides of this approach: (a) We have to perform the
entire copy operation again if there is any error (network breakdown,
error in the database operation, etc.) while we synchronize the WAL
position between tablesync worker and apply worker; this will be onerous
especially for large copies, (b) Using a single transaction in the
synchronization-phase (where we can receive WAL from multiple
transactions) will have the risk of exceeding the CID limit, (c) The slot
will hold the WAL till the entire sync is complete because we never commit
till the end.
This patch solves all the above downsides by allowing multiple
transactions during the tablesync phase. The initial copy is done in a
single transaction and after that, we commit each transaction as we
receive. To allow recovery after any error or crash, we use a permanent
slot and origin to track the progress. The slot and origin will be removed
once we finish the synchronization of the table. We also remove slot and
origin of tablesync workers if the user performs DROP SUBSCRIPTION .. or
ALTER SUBSCRIPTION .. REFERESH and some of the table syncs are still not
finished.
The commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION and
ALTER SUBSCRIPTION ... SET PUBLICATION ... with refresh option as true
cannot be executed inside a transaction block because they can now drop
the slots for which we have no provision to rollback.
This will also open up the path for logical replication of 2PC
transactions on the subscriber side. Previously, we can't do that because
of the requirement of maintaining a single transaction in tablesync
workers.
Bump catalog version due to change of state in the catalog
(pg_subscription_rel).
Author: Peter Smith, Amit Kapila, and Takamichi Osumi
Reviewed-by: Ajin Cherian, Petr Jelinek, Hou Zhijie and Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1KHJxaZS-fod-0fey=0tq3=Gkn4ho=8N4-5HWiCfu0H1A@mail.gmail.com
2021-02-12 03:11:51 +01:00
<literal>f</literal> = finished table copy,
2017-10-09 03:44:17 +02:00
<literal>s</literal> = synchronized,
<literal>r</literal> = ready (normal replication)
2020-05-14 05:03:39 +02:00
</para></entry>
2017-03-23 13:36:36 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>srsublsn</structfield> <type>pg_lsn</type>
</para>
<para>
2020-07-20 20:55:56 +02:00
Remote LSN of the state change used for synchronization coordination
when in <literal>s</literal> or <literal>r</literal> states,
otherwise null
2020-05-14 05:03:39 +02:00
</para></entry>
2017-03-23 13:36:36 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2004-06-18 08:14:31 +02:00
<sect1 id="catalog-pg-tablespace">
<title><structname>pg_tablespace</structname></title>
<indexterm zone="catalog-pg-tablespace">
<primary>pg_tablespace</primary>
</indexterm>
<para>
The catalog <structname>pg_tablespace</structname> stores information
about the available tablespaces. Tables can be placed in particular
tablespaces to aid administration of disk layout.
</para>
<para>
Unlike most system catalogs, <structname>pg_tablespace</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_tablespace</structname> per cluster, not
one per database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_tablespace</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2004-06-18 08:14:31 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2004-06-18 08:14:31 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2004-06-18 08:14:31 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spcname</structfield> <type>name</type>
</para>
<para>
Tablespace name
</para></entry>
2004-06-18 08:14:31 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spcowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the tablespace, usually the user who created it
</para></entry>
2004-06-18 08:14:31 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spcacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2004-06-18 08:14:31 +02:00
</row>
2010-01-10 02:23:08 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spcoptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Tablespace-level options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2010-01-10 02:23:08 +01:00
</row>
2004-06-18 08:14:31 +02:00
</tbody>
</tgroup>
</table>
</sect1>
2015-04-26 16:33:14 +02:00
<sect1 id="catalog-pg-transform">
<title><structname>pg_transform</structname></title>
<indexterm zone="catalog-pg-transform">
<primary>pg_transform</primary>
</indexterm>
<para>
The catalog <structname>pg_transform</structname> stores information about
transforms, which are a mechanism to adapt data types to procedural
2017-11-23 15:39:47 +01:00
languages. See <xref linkend="sql-createtransform"/> for more information.
2015-04-26 16:33:14 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_transform</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2015-04-26 16:33:14 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2015-04-26 16:33:14 +02:00
</row>
</thead>
<tbody>
2020-05-10 01:09:44 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2020-05-10 01:09:44 +02:00
</row>
2015-04-26 16:33:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>trftype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the data type this transform is for
</para></entry>
2015-04-26 16:33:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>trflang</structfield> <type>oid</type>
(references <link linkend="catalog-pg-language"><structname>pg_language</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the language this transform is for
</para></entry>
2015-04-26 16:33:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>trffromsql</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2015-04-26 16:33:14 +02:00
The OID of the function to use when converting the data type for input
to the procedural language (e.g., function parameters). Zero is stored
2021-02-02 22:15:29 +01:00
if the default behavior should be used.
2020-05-14 05:03:39 +02:00
</para></entry>
2015-04-26 16:33:14 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>trftosql</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2015-04-26 16:33:14 +02:00
The OID of the function to use when converting output from the
procedural language (e.g., return values) to the data type. Zero is
2021-02-02 22:15:29 +01:00
stored if the default behavior should be used.
2020-05-14 05:03:39 +02:00
</para></entry>
2015-04-26 16:33:14 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-trigger">
2003-04-15 15:23:35 +02:00
<title><structname>pg_trigger</structname></title>
<indexterm zone="catalog-pg-trigger">
<primary>pg_trigger</primary>
</indexterm>
2001-10-16 00:47:47 +02:00
<para>
2010-10-10 19:43:33 +02:00
The catalog <structname>pg_trigger</structname> stores triggers on tables
and views.
2017-11-23 15:39:47 +01:00
See <xref linkend="sql-createtrigger"/>
2005-01-06 00:42:03 +01:00
for more information.
2001-10-16 00:47:47 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_trigger</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2001-10-16 00:47:47 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2001-10-16 00:47:47 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table this trigger is on
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
2020-02-27 17:23:33 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgparentid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-trigger"><structname>pg_trigger</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Parent trigger that this trigger is cloned from (this happens when
partitions are created or attached to a partitioned table);
zero if not a clone
2020-05-14 05:03:39 +02:00
</para></entry>
2020-02-27 17:23:33 +01:00
</row>
2001-10-16 00:47:47 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgname</structfield> <type>name</type>
</para>
<para>
Trigger name (must be unique among triggers of same table)
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgfoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The function to be called
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgtype</structfield> <type>int2</type>
</para>
<para>
Bit mask identifying trigger firing conditions
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgenabled</structfield> <type>char</type>
</para>
<para>
2017-11-23 15:39:47 +01:00
Controls in which <xref linkend="guc-session-replication-role"/> modes
2007-03-22 16:46:56 +01:00
the trigger fires.
2017-10-09 03:44:17 +02:00
<literal>O</literal> = trigger fires in <quote>origin</quote> and <quote>local</quote> modes,
<literal>D</literal> = trigger is disabled,
<literal>R</literal> = trigger fires in <quote>replica</quote> mode,
<literal>A</literal> = trigger fires always.
2020-05-14 05:03:39 +02:00
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgisinternal</structfield> <type>bool</type>
</para>
<para>
True if trigger is internally generated (usually, to enforce
the constraint identified by <structfield>tgconstraint</structfield>)
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgconstrrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The table referenced by a referential integrity constraint
2021-02-02 22:15:29 +01:00
(zero if trigger is not for a referential integrity constraint)
2020-05-14 05:03:39 +02:00
</para></entry>
2007-02-14 02:58:58 +01:00
</row>
2009-07-28 04:56:31 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgconstrindid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The index supporting a unique, primary key, referential integrity,
or exclusion constraint
2021-02-02 22:15:29 +01:00
(zero if trigger is not for one of these types of constraint)
2020-05-14 05:03:39 +02:00
</para></entry>
2009-07-28 04:56:31 +02:00
</row>
2007-02-14 02:58:58 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgconstraint</structfield> <type>oid</type>
(references <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
The <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> entry associated with the trigger
(zero if trigger is not for a constraint)
2020-05-14 05:03:39 +02:00
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgdeferrable</structfield> <type>bool</type>
</para>
<para>
True if constraint trigger is deferrable
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tginitdeferred</structfield> <type>bool</type>
</para>
<para>
True if constraint trigger is initially deferred
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgnargs</structfield> <type>int2</type>
</para>
<para>
Number of argument strings passed to trigger function
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgattr</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
Column numbers, if trigger is column-specific; otherwise an
empty array
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgargs</structfield> <type>bytea</type>
</para>
<para>
Argument strings to pass to trigger, each NULL-terminated
</para></entry>
2001-10-16 00:47:47 +02:00
</row>
2009-11-20 21:38:12 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgqual</structfield> <type>pg_node_tree</type>
</para>
<para>
Expression tree (in <function>nodeToString()</function>
2017-10-09 03:44:17 +02:00
representation) for the trigger's <literal>WHEN</literal> condition, or null
2020-05-14 05:03:39 +02:00
if none
</para></entry>
2009-11-20 21:38:12 +01:00
</row>
2016-11-04 16:49:50 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgoldtable</structfield> <type>name</type>
</para>
<para>
<literal>REFERENCING</literal> clause name for <literal>OLD TABLE</literal>,
or null if none
</para></entry>
2016-11-04 16:49:50 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tgnewtable</structfield> <type>name</type>
</para>
<para>
<literal>REFERENCING</literal> clause name for <literal>NEW TABLE</literal>,
or null if none
</para></entry>
2016-11-04 16:49:50 +01:00
</row>
2001-10-16 00:47:47 +02:00
</tbody>
</tgroup>
</table>
2009-10-15 00:14:25 +02:00
<para>
Currently, column-specific triggering is supported only for
2017-10-09 03:44:17 +02:00
<literal>UPDATE</literal> events, and so <structfield>tgattr</structfield> is relevant
2009-10-15 00:14:25 +02:00
only for that event type. <structfield>tgtype</structfield> might
contain bits for other event types as well, but those are presumed
2017-10-09 03:44:17 +02:00
to be table-wide regardless of what is in <structfield>tgattr</structfield>.
2009-10-15 00:14:25 +02:00
</para>
2007-02-14 02:58:58 +01:00
<note>
<para>
2017-10-09 03:44:17 +02:00
When <structfield>tgconstraint</structfield> is nonzero,
<structfield>tgconstrrelid</structfield>, <structfield>tgconstrindid</structfield>,
<structfield>tgdeferrable</structfield>, and <structfield>tginitdeferred</structfield> are
2020-09-03 13:15:53 +02:00
largely redundant with the referenced <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> entry.
2010-01-17 23:56:23 +01:00
However, it is possible for a non-deferrable trigger to be associated
with a deferrable constraint: foreign key constraints can have some
deferrable and some non-deferrable triggers.
2007-02-14 02:58:58 +01:00
</para>
</note>
2008-11-10 01:49:37 +01:00
<note>
<para>
<literal>pg_class.relhastriggers</literal>
2010-10-10 19:43:33 +02:00
must be true if a relation has any triggers in this catalog.
2008-11-10 01:49:37 +01:00
</para>
</note>
2001-11-09 00:44:01 +01:00
</sect1>
2001-10-16 00:47:47 +02:00
2007-10-01 23:10:40 +02:00
<sect1 id="catalog-pg-ts-config">
<title><structname>pg_ts_config</structname></title>
<indexterm zone="catalog-pg-ts-config">
<primary>pg_ts_config</primary>
</indexterm>
<para>
The <structname>pg_ts_config</structname> catalog contains entries
representing text search configurations. A configuration specifies
a particular text search parser and a list of dictionaries to use
for each of the parser's output token types. The parser is shown
in the <structname>pg_ts_config</structname> entry, but the
token-to-dictionary mapping is defined by subsidiary entries in <link
linkend="catalog-pg-ts-config-map"><structname>pg_ts_config_map</structname></link>.
</para>
<para>
<productname>PostgreSQL</productname>'s text search features are
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
2007-10-01 23:10:40 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_config</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2007-10-01 23:10:40 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2007-10-01 23:10:40 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cfgname</structfield> <type>name</type>
</para>
<para>
Text search configuration name
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cfgnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this configuration
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cfgowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the configuration
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cfgparser</structfield> <type>oid</type>
(references <link linkend="catalog-pg-ts-parser"><structname>pg_ts_parser</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the text search parser for this configuration
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="catalog-pg-ts-config-map">
<title><structname>pg_ts_config_map</structname></title>
<indexterm zone="catalog-pg-ts-config-map">
<primary>pg_ts_config_map</primary>
</indexterm>
<para>
The <structname>pg_ts_config_map</structname> catalog contains entries
showing which text search dictionaries should be consulted, and in
what order, for each output token type of each text search configuration's
parser.
</para>
<para>
<productname>PostgreSQL</productname>'s text search features are
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
2007-10-01 23:10:40 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_config_map</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2007-10-01 23:10:40 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>mapcfg</structfield> <type>oid</type>
(references <link linkend="catalog-pg-ts-config"><structname>pg_ts_config</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2020-09-03 13:15:53 +02:00
The OID of the <link linkend="catalog-pg-ts-config"><structname>pg_ts_config</structname></link> entry owning this map entry
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>maptokentype</structfield> <type>int4</type>
</para>
<para>
A token type emitted by the configuration's parser
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>mapseqno</structfield> <type>int4</type>
</para>
<para>
Order in which to consult this entry (lower
<structfield>mapseqno</structfield>s first)
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>mapdict</structfield> <type>oid</type>
(references <link linkend="catalog-pg-ts-dict"><structname>pg_ts_dict</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the text search dictionary to consult
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="catalog-pg-ts-dict">
<title><structname>pg_ts_dict</structname></title>
<indexterm zone="catalog-pg-ts-dict">
<primary>pg_ts_dict</primary>
</indexterm>
<para>
The <structname>pg_ts_dict</structname> catalog contains entries
defining text search dictionaries. A dictionary depends on a text
search template, which specifies all the implementation functions
needed; the dictionary itself provides values for the user-settable
parameters supported by the template. This division of labor allows
dictionaries to be created by unprivileged users. The parameters
2017-10-09 03:44:17 +02:00
are specified by a text string <structfield>dictinitoption</structfield>,
2007-10-01 23:10:40 +02:00
whose format and meaning vary depending on the template.
</para>
<para>
<productname>PostgreSQL</productname>'s text search features are
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
2007-10-01 23:10:40 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_dict</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2007-10-01 23:10:40 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2007-10-01 23:10:40 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dictname</structfield> <type>name</type>
</para>
<para>
Text search dictionary name
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dictnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this dictionary
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dictowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the dictionary
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dicttemplate</structfield> <type>oid</type>
(references <link linkend="catalog-pg-ts-template"><structname>pg_ts_template</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The OID of the text search template for this dictionary
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dictinitoption</structfield> <type>text</type>
</para>
<para>
Initialization option string for the template
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="catalog-pg-ts-parser">
<title><structname>pg_ts_parser</structname></title>
<indexterm zone="catalog-pg-ts-parser">
<primary>pg_ts_parser</primary>
</indexterm>
<para>
The <structname>pg_ts_parser</structname> catalog contains entries
defining text search parsers. A parser is responsible for splitting
input text into lexemes and assigning a token type to each lexeme.
Since a parser must be implemented by C-language-level functions,
creation of new parsers is restricted to database superusers.
</para>
<para>
<productname>PostgreSQL</productname>'s text search features are
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
2007-10-01 23:10:40 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_parser</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2007-10-01 23:10:40 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2007-10-01 23:10:40 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prsname</structfield> <type>name</type>
</para>
<para>
Text search parser name
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prsnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this parser
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prsstart</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the parser's startup function
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prstoken</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the parser's next-token function
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prsend</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the parser's shutdown function
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prsheadline</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
OID of the parser's headline function (zero if none)
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prslextype</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the parser's lextype function
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="catalog-pg-ts-template">
<title><structname>pg_ts_template</structname></title>
<indexterm zone="catalog-pg-ts-template">
<primary>pg_ts_template</primary>
</indexterm>
<para>
The <structname>pg_ts_template</structname> catalog contains entries
defining text search templates. A template is the implementation
skeleton for a class of text search dictionaries.
Since a template must be implemented by C-language-level functions,
creation of new templates is restricted to database superusers.
</para>
<para>
<productname>PostgreSQL</productname>'s text search features are
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
2007-10-01 23:10:40 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_template</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2007-10-01 23:10:40 +02:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2007-10-01 23:10:40 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tmplname</structfield> <type>name</type>
</para>
<para>
Text search template name
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tmplnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this template
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tmplinit</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
OID of the template's initialization function (zero if none)
2020-05-14 05:03:39 +02:00
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tmpllexize</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the template's lexize function
</para></entry>
2007-10-01 23:10:40 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-type">
2003-04-15 15:23:35 +02:00
<title><structname>pg_type</structname></title>
<indexterm zone="catalog-pg-type">
<primary>pg_type</primary>
</indexterm>
2000-11-29 21:15:59 +01:00
2001-10-16 00:47:47 +02:00
<para>
2005-01-06 00:42:03 +01:00
The catalog <structname>pg_type</structname> stores information about data
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
types. Base types and enum types (scalar types) are created with
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-createtype"><command>CREATE TYPE</command></link>, and
2005-01-06 00:42:03 +01:00
domains with
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<link linkend="sql-createdomain"><command>CREATE DOMAIN</command></link>.
2003-05-09 00:19:58 +02:00
A composite type is automatically created for each table in the database, to
2002-03-20 20:45:13 +01:00
represent the row structure of the table. It is also possible to create
2005-01-06 00:42:03 +01:00
composite types with <command>CREATE TYPE AS</command>.
2001-10-16 00:47:47 +02:00
</para>
2000-11-29 21:15:59 +01:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_type</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2000-11-29 21:15:59 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typname</structfield> <type>name</type>
</para>
<para>
Data type name
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2002-03-29 20:06:29 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2002-03-29 20:06:29 +01:00
The OID of the namespace that contains this type
2020-05-14 05:03:39 +02:00
</para></entry>
2002-03-29 20:06:29 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typowner</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Owner of the type
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typlen</structfield> <type>int2</type>
</para>
<para>
2002-08-24 17:00:47 +02:00
For a fixed-size type, <structfield>typlen</structfield> is the number
of bytes in the internal representation of the type. But for a
variable-length type, <structfield>typlen</structfield> is negative.
2017-10-09 03:44:17 +02:00
-1 indicates a <quote>varlena</quote> type (one that has a length word),
2002-08-24 17:00:47 +02:00
-2 indicates a null-terminated C string.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typbyval</structfield> <type>bool</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
<structfield>typbyval</structfield> determines whether internal
routines pass a value of this type by value or by reference.
2003-05-09 00:19:58 +02:00
<structfield>typbyval</structfield> had better be false if
<structfield>typlen</structfield> is not 1, 2, or 4 (or 8 on machines
where Datum is 8 bytes).
2000-11-29 21:15:59 +01:00
Variable-length types are always passed by reference. Note that
<structfield>typbyval</structfield> can be false even if the
2010-08-17 06:37:21 +02:00
length would allow pass-by-value.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typtype</structfield> <type>char</type>
</para>
<para>
2007-04-02 05:49:42 +02:00
<structfield>typtype</structfield> is
<literal>b</literal> for a base type,
<literal>c</literal> for a composite type (e.g., a table's row type),
<literal>d</literal> for a domain,
<literal>e</literal> for an enum type,
Multirange datatypes
Multiranges are basically sorted arrays of non-overlapping ranges with
set-theoretic operations defined over them.
Since v14, each range type automatically gets a corresponding multirange
datatype. There are both manual and automatic mechanisms for naming multirange
types. Once can specify multirange type name using multirange_type_name
attribute in CREATE TYPE. Otherwise, a multirange type name is generated
automatically. If the range type name contains "range" then we change that to
"multirange". Otherwise, we add "_multirange" to the end.
Implementation of multiranges comes with a space-efficient internal
representation format, which evades extra paddings and duplicated storage of
oids. Altogether this format allows fetching a particular range by its index
in O(n).
Statistic gathering and selectivity estimation are implemented for multiranges.
For this purpose, stored multirange is approximated as union range without gaps.
This field will likely need improvements in the future.
Catversion is bumped.
Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com
Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0
Author: Paul Jungwirth, revised by me
Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule
Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston
Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
<literal>p</literal> for a pseudo-type,
<literal>r</literal> for a range type, or
<literal>m</literal> for a multirange type.
2007-04-02 05:49:42 +02:00
See also <structfield>typrelid</structfield> and
2010-08-17 06:37:21 +02:00
<structfield>typbasetype</structfield>.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typcategory</structfield> <type>char</type>
</para>
<para>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
<structfield>typcategory</structfield> is an arbitrary classification
of data types that is used by the parser to determine which implicit
2017-10-09 03:44:17 +02:00
casts should be <quote>preferred</quote>.
2017-11-23 15:39:47 +01:00
See <xref linkend="catalog-typcategory-table"/>.
2020-05-14 05:03:39 +02:00
</para></entry>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typispreferred</structfield> <type>bool</type>
</para>
<para>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
True if the type is a preferred cast target within its
<structfield>typcategory</structfield>
2020-05-14 05:03:39 +02:00
</para></entry>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typisdefined</structfield> <type>bool</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
True if the type is defined, false if this is a placeholder
entry for a not-yet-defined type. When
<structfield>typisdefined</structfield> is false, nothing
2010-08-17 06:37:21 +02:00
except the type name, namespace, and OID can be relied on.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typdelim</structfield> <type>char</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
Character that separates two values of this type when parsing
array input. Note that the delimiter is associated with the array
2010-08-17 06:37:21 +02:00
element data type, not the array data type.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typrelid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2003-05-09 00:19:58 +02:00
If this is a composite type (see
2003-04-15 15:23:35 +02:00
<structfield>typtype</structfield>), then this column points to
2020-09-03 13:15:53 +02:00
the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry that defines the
2002-08-28 17:02:55 +02:00
corresponding table. (For a free-standing composite type, the
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry doesn't really represent
2002-08-28 17:02:55 +02:00
a table, but it is needed anyway for the type's
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link> entries to link to.)
2010-08-17 06:37:21 +02:00
Zero for non-composite types.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
Support subscripting of arbitrary types, not only arrays.
This patch generalizes the subscripting infrastructure so that any
data type can be subscripted, if it provides a handler function to
define what that means. Traditional variable-length (varlena) arrays
all use array_subscript_handler(), while the existing fixed-length
types that support subscripting use raw_array_subscript_handler().
It's expected that other types that want to use subscripting notation
will define their own handlers. (This patch provides no such new
features, though; it only lays the foundation for them.)
To do this, move the parser's semantic processing of subscripts
(including coercion to whatever data type is required) into a
method callback supplied by the handler. On the execution side,
replace the ExecEvalSubscriptingRef* layer of functions with direct
calls to callback-supplied execution routines. (Thus, essentially
no new run-time overhead should be caused by this patch. Indeed,
there is room to remove some overhead by supplying specialized
execution routines. This patch does a little bit in that line,
but more could be done.)
Additional work is required here and there to remove formerly
hard-wired assumptions about the result type, collation, etc
of a SubscriptingRef expression node; and to remove assumptions
that the subscript values must be integers.
One useful side-effect of this is that we now have a less squishy
mechanism for identifying whether a data type is a "true" array:
instead of wiring in weird rules about typlen, we can look to see
if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this
to be bulletproof, we have to forbid user-defined types from using
that handler directly; but there seems no good reason for them to
do so.
This patch also removes assumptions that the number of subscripts
is limited to MAXDIM (6), or indeed has any hard-wired limit.
That limit still applies to types handled by array_subscript_handler
or raw_array_subscript_handler, but to discourage other dependencies
on this constant, I've moved it from c.h to utils/array.h.
Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov,
Peter Eisentraut, Pavel Stehule
Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com
Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typsubscript</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Subscripting handler function's OID, or zero if this type doesn't
support subscripting. Types that are <quote>true</quote> array
types have <structfield>typsubscript</structfield>
= <function>array_subscript_handler</function>, but other types may
have other handler functions to implement specialized subscripting
behavior.
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typelem</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
If <structfield>typelem</structfield> is not zero then it
Support subscripting of arbitrary types, not only arrays.
This patch generalizes the subscripting infrastructure so that any
data type can be subscripted, if it provides a handler function to
define what that means. Traditional variable-length (varlena) arrays
all use array_subscript_handler(), while the existing fixed-length
types that support subscripting use raw_array_subscript_handler().
It's expected that other types that want to use subscripting notation
will define their own handlers. (This patch provides no such new
features, though; it only lays the foundation for them.)
To do this, move the parser's semantic processing of subscripts
(including coercion to whatever data type is required) into a
method callback supplied by the handler. On the execution side,
replace the ExecEvalSubscriptingRef* layer of functions with direct
calls to callback-supplied execution routines. (Thus, essentially
no new run-time overhead should be caused by this patch. Indeed,
there is room to remove some overhead by supplying specialized
execution routines. This patch does a little bit in that line,
but more could be done.)
Additional work is required here and there to remove formerly
hard-wired assumptions about the result type, collation, etc
of a SubscriptingRef expression node; and to remove assumptions
that the subscript values must be integers.
One useful side-effect of this is that we now have a less squishy
mechanism for identifying whether a data type is a "true" array:
instead of wiring in weird rules about typlen, we can look to see
if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this
to be bulletproof, we have to forbid user-defined types from using
that handler directly; but there seems no good reason for them to
do so.
This patch also removes assumptions that the number of subscripts
is limited to MAXDIM (6), or indeed has any hard-wired limit.
That limit still applies to types handled by array_subscript_handler
or raw_array_subscript_handler, but to discourage other dependencies
on this constant, I've moved it from c.h to utils/array.h.
Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov,
Peter Eisentraut, Pavel Stehule
Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com
Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
identifies another row in <structname>pg_type</structname>,
2021-02-02 22:15:29 +01:00
defining the type yielded by subscripting. This should be zero
if <structfield>typsubscript</structfield> is zero. However, it can
be zero when <structfield>typsubscript</structfield> isn't zero, if the
Support subscripting of arbitrary types, not only arrays.
This patch generalizes the subscripting infrastructure so that any
data type can be subscripted, if it provides a handler function to
define what that means. Traditional variable-length (varlena) arrays
all use array_subscript_handler(), while the existing fixed-length
types that support subscripting use raw_array_subscript_handler().
It's expected that other types that want to use subscripting notation
will define their own handlers. (This patch provides no such new
features, though; it only lays the foundation for them.)
To do this, move the parser's semantic processing of subscripts
(including coercion to whatever data type is required) into a
method callback supplied by the handler. On the execution side,
replace the ExecEvalSubscriptingRef* layer of functions with direct
calls to callback-supplied execution routines. (Thus, essentially
no new run-time overhead should be caused by this patch. Indeed,
there is room to remove some overhead by supplying specialized
execution routines. This patch does a little bit in that line,
but more could be done.)
Additional work is required here and there to remove formerly
hard-wired assumptions about the result type, collation, etc
of a SubscriptingRef expression node; and to remove assumptions
that the subscript values must be integers.
One useful side-effect of this is that we now have a less squishy
mechanism for identifying whether a data type is a "true" array:
instead of wiring in weird rules about typlen, we can look to see
if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this
to be bulletproof, we have to forbid user-defined types from using
that handler directly; but there seems no good reason for them to
do so.
This patch also removes assumptions that the number of subscripts
is limited to MAXDIM (6), or indeed has any hard-wired limit.
That limit still applies to types handled by array_subscript_handler
or raw_array_subscript_handler, but to discourage other dependencies
on this constant, I've moved it from c.h to utils/array.h.
Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov,
Peter Eisentraut, Pavel Stehule
Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com
Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
handler doesn't need <structfield>typelem</structfield> to
determine the subscripting result type.
Note that a <structfield>typelem</structfield> dependency is
considered to imply physical containment of the element type in
this type; so DDL changes on the element type might be restricted
by the presence of this type.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
Support arrays of composite types, including the rowtypes of regular tables
and views (but not system catalogs, nor sequences or toast tables). Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage. (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)
Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.
David Fetter, Andrew Dunstan, Tom Lane
2007-05-11 19:57:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typarray</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
If <structfield>typarray</structfield> is not zero then it
Support arrays of composite types, including the rowtypes of regular tables
and views (but not system catalogs, nor sequences or toast tables). Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage. (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)
Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.
David Fetter, Andrew Dunstan, Tom Lane
2007-05-11 19:57:14 +02:00
identifies another row in <structname>pg_type</structname>, which
is the <quote>true</quote> array type having this type as element
2020-05-14 05:03:39 +02:00
</para></entry>
Support arrays of composite types, including the rowtypes of regular tables
and views (but not system catalogs, nor sequences or toast tables). Get rid
of the hardwired convention that a type's array type is named exactly "_type",
instead using a new column pg_type.typarray to provide the linkage. (It still
will be named "_type", though, except in odd corner cases such as
maximum-length type names.)
Along the way, make tracking of owner and schema dependencies for types more
uniform: a type directly created by the user has these dependencies, while a
table rowtype or auto-generated array type does not have them, but depends on
its parent object instead.
David Fetter, Andrew Dunstan, Tom Lane
2007-05-11 19:57:14 +02:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typinput</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Input conversion function (text format)
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typoutput</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Output conversion function (text format)
</para></entry>
2003-05-09 00:19:58 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typreceive</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Input conversion function (binary format), or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2003-05-09 00:19:58 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typsend</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Output conversion function (binary format), or zero if none
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2006-12-30 22:21:56 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typmodin</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Type modifier input function, or zero if type does not support modifiers
2020-05-14 05:03:39 +02:00
</para></entry>
2006-12-30 22:21:56 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typmodout</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Type modifier output function, or zero to use the standard format
2020-05-14 05:03:39 +02:00
</para></entry>
2006-12-30 22:21:56 +01:00
</row>
2004-02-13 00:41:04 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typanalyze</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
Custom <xref linkend="sql-analyze"/> function,
or zero to use the standard function
2020-05-14 05:03:39 +02:00
</para></entry>
2004-02-13 00:41:04 +01:00
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typalign</structfield> <type>char</type>
</para>
<para>
2000-11-29 21:15:59 +01:00
<structfield>typalign</structfield> is the alignment required
when storing a value of this type. It applies to storage on
disk as well as most representations of the value inside
2017-10-09 03:44:17 +02:00
<productname>PostgreSQL</productname>.
2002-09-22 21:42:52 +02:00
When multiple values are stored consecutively, such
2000-11-29 21:15:59 +01:00
as in the representation of a complete row on disk, padding is
inserted before a datum of this type so that it begins on the
specified boundary. The alignment reference is the beginning
of the first datum in the sequence.
Possible values are:
<itemizedlist>
<listitem>
2017-10-09 03:44:17 +02:00
<para><literal>c</literal> = <type>char</type> alignment, i.e., no alignment needed.</para>
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
2017-10-09 03:44:17 +02:00
<para><literal>s</literal> = <type>short</type> alignment (2 bytes on most machines).</para>
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
2017-10-09 03:44:17 +02:00
<para><literal>i</literal> = <type>int</type> alignment (4 bytes on most machines).</para>
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
2017-10-09 03:44:17 +02:00
<para><literal>d</literal> = <type>double</type> alignment (8 bytes on many machines, but by no means all).</para>
2000-11-29 21:15:59 +01:00
</listitem>
</itemizedlist>
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typstorage</structfield> <type>char</type>
</para>
<para>
2002-08-24 17:00:47 +02:00
<structfield>typstorage</structfield> tells for varlena
2000-11-29 21:15:59 +01:00
types (those with <structfield>typlen</structfield> = -1) if
the type is prepared for toasting and what the default strategy
for attributes of this type should be.
2020-03-06 18:19:29 +01:00
Possible values are:
2000-11-29 21:15:59 +01:00
<itemizedlist>
<listitem>
2020-03-06 18:19:29 +01:00
<para>
<literal>p</literal> (plain): Values must always be stored plain
(non-varlena types always use this value).
</para>
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
<para>
2020-03-06 18:19:29 +01:00
<literal>e</literal> (external): Values can be stored in a
secondary <quote>TOAST</quote> relation (if relation has one, see
2003-04-15 15:23:35 +02:00
<literal>pg_class.reltoastrelid</literal>).
2000-11-29 21:15:59 +01:00
</para>
</listitem>
<listitem>
2020-03-06 18:19:29 +01:00
<para>
<literal>m</literal> (main): Values can be compressed and stored
inline.
</para>
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
2020-03-06 18:19:29 +01:00
<para>
<literal>x</literal> (extended): Values can be compressed and/or
moved to a secondary relation.
</para>
2000-11-29 21:15:59 +01:00
</listitem>
</itemizedlist>
2020-03-06 18:19:29 +01:00
<literal>x</literal> is the usual choice for toast-able types.
Note that <literal>m</literal> values can also be moved out to
secondary storage, but only as a last resort (<literal>e</literal>
and <literal>x</literal> values are moved first).
2000-11-29 21:15:59 +01:00
</para></entry>
</row>
2002-03-19 03:18:25 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typnotnull</structfield> <type>bool</type>
</para>
<para>
2003-04-15 15:23:35 +02:00
<structfield>typnotnull</structfield> represents a not-null
2010-08-17 06:37:21 +02:00
constraint on a type. Used for domains only.
2002-03-19 03:18:25 +01:00
</para></entry>
</row>
2002-03-20 20:45:13 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typbasetype</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2006-11-12 07:25:37 +01:00
If this is a domain (see <structfield>typtype</structfield>), then
<structfield>typbasetype</structfield> identifies the type that this
2010-08-17 06:37:21 +02:00
one is based on. Zero if this type is not a domain.
2002-03-20 20:45:13 +01:00
</para></entry>
</row>
2002-03-19 03:18:25 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typtypmod</structfield> <type>int4</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
Domains use <structfield>typtypmod</structfield> to record the <literal>typmod</literal>
2002-09-24 23:26:44 +02:00
to be applied to their base type (-1 if base type does not use a
2017-10-09 03:44:17 +02:00
<literal>typmod</literal>). -1 if this type is not a domain.
2002-09-24 23:26:44 +02:00
</para></entry>
2002-03-20 20:45:13 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typndims</structfield> <type>int4</type>
</para>
<para>
2002-03-20 20:45:13 +01:00
<structfield>typndims</structfield> is the number of array dimensions
2017-10-09 03:44:17 +02:00
for a domain over an array (that is, <structfield>typbasetype</structfield> is
Improve handling of domains over arrays.
This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied. If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.
For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints. For the
moment, we just forbid such matching. We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.
To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead. In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.
Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
an array type).
2010-08-17 06:37:21 +02:00
Zero for types other than domains over array types.
2020-05-14 05:03:39 +02:00
</para></entry>
2002-03-19 03:18:25 +01:00
</row>
2011-02-08 22:04:18 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typcollation</structfield> <type>oid</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2011-02-08 22:04:18 +01:00
<structfield>typcollation</structfield> specifies the collation
2011-03-08 23:10:34 +01:00
of the type. If the type does not support collations, this will
Make type "name" collation-aware.
The "name" comparison operators now all support collations, making them
functionally equivalent to "text" comparisons, except for the different
physical representation of the datatype. They do, in fact, mostly share
the varstr_cmp and varstr_sortsupport infrastructure, which has been
slightly enlarged to handle the case.
To avoid changes in the default behavior of the datatype, set name's
typcollation to C_COLLATION_OID not DEFAULT_COLLATION_OID, so that
by default comparisons to a name value will continue to use strcmp
semantics. (This would have been the case for system catalog columns
anyway, because of commit 6b0faf723, but doing this makes it true for
user-created name columns as well. In particular, this avoids
locale-dependent changes in our regression test results.)
In consequence, tweak a couple of places that made assumptions about
collatable base types always having typcollation DEFAULT_COLLATION_OID.
I have not, however, attempted to relax the restriction that user-
defined collatable types must have that. Hence, "name" doesn't
behave quite like a user-defined type; it acts more like a domain
with COLLATE "C". (Conceivably, if we ever get rid of the need for
catalog name columns to be fixed-length, "name" could actually become
such a domain over text. But that'd be a pretty massive undertaking,
and I'm not volunteering.)
Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
2018-12-19 23:35:12 +01:00
be zero. A base type that supports collations will have a nonzero
value here, typically <symbol>DEFAULT_COLLATION_OID</symbol>.
A domain over a collatable type can have a collation OID different
from its base type's, if one was specified for the domain.
2011-02-08 22:04:18 +01:00
</para></entry>
</row>
2002-03-19 03:18:25 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typdefaultbin</structfield> <type>pg_node_tree</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
If <structfield>typdefaultbin</structfield> is not null, it is the
2010-09-03 03:34:55 +02:00
<function>nodeToString()</function>
2003-04-15 15:23:35 +02:00
representation of a default expression for the type. This is
2010-08-17 06:37:21 +02:00
only used for domains.
2002-03-19 03:18:25 +01:00
</para></entry>
</row>
2000-11-29 21:15:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typdefault</structfield> <type>text</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
<structfield>typdefault</structfield> is null if the type has no associated
default value. If <structfield>typdefaultbin</structfield> is not null,
<structfield>typdefault</structfield> must contain a human-readable version of the
default expression represented by <structfield>typdefaultbin</structfield>. If
<structfield>typdefaultbin</structfield> is null and <structfield>typdefault</structfield> is
not, then <structfield>typdefault</structfield> is the external representation of
2010-09-03 03:34:55 +02:00
the type's default value, which can be fed to the type's input
2010-08-17 06:37:21 +02:00
converter to produce a constant.
2001-09-06 04:07:42 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2012-04-06 22:54:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typacl</structfield> <type>aclitem[]</type>
</para>
<para>
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
2020-05-14 05:03:39 +02:00
</para></entry>
2012-04-06 22:54:27 +02:00
</row>
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
2020-05-14 05:03:39 +02:00
<note>
<para>
For fixed-width types used in system tables, it is critical that the size
and alignment defined in <structname>pg_type</structname>
agree with the way that the compiler will lay out the column in
a structure representing a table row.
</para>
</note>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
<para>
2017-11-23 15:39:47 +01:00
<xref linkend="catalog-typcategory-table"/> lists the system-defined values
2017-10-09 03:44:17 +02:00
of <structfield>typcategory</structfield>. Any future additions to this list will
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
also be upper-case ASCII letters. All other ASCII characters are reserved
for user-defined categories.
</para>
<table id="catalog-typcategory-table">
2017-10-09 03:44:17 +02:00
<title><structfield>typcategory</structfield> Codes</title>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
2009-02-04 22:30:41 +01:00
<tgroup cols="2">
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
<thead>
<row>
<entry>Code</entry>
<entry>Category</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>A</literal></entry>
<entry>Array types</entry>
</row>
<row>
<entry><literal>B</literal></entry>
<entry>Boolean types</entry>
</row>
<row>
<entry><literal>C</literal></entry>
<entry>Composite types</entry>
</row>
<row>
<entry><literal>D</literal></entry>
<entry>Date/time types</entry>
</row>
<row>
<entry><literal>E</literal></entry>
<entry>Enum types</entry>
</row>
<row>
<entry><literal>G</literal></entry>
<entry>Geometric types</entry>
</row>
<row>
<entry><literal>I</literal></entry>
<entry>Network address types</entry>
</row>
<row>
<entry><literal>N</literal></entry>
<entry>Numeric types</entry>
</row>
<row>
<entry><literal>P</literal></entry>
<entry>Pseudo-types</entry>
</row>
2011-11-19 00:23:55 +01:00
<row>
<entry><literal>R</literal></entry>
<entry>Range types</entry>
</row>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
<row>
<entry><literal>S</literal></entry>
<entry>String types</entry>
</row>
<row>
<entry><literal>T</literal></entry>
<entry>Timespan types</entry>
</row>
<row>
<entry><literal>U</literal></entry>
<entry>User-defined types</entry>
</row>
<row>
<entry><literal>V</literal></entry>
<entry>Bit-string types</entry>
</row>
<row>
<entry><literal>X</literal></entry>
2017-10-09 03:44:17 +02:00
<entry><type>unknown</type> type</entry>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
</row>
2021-12-11 20:10:51 +01:00
<row>
<entry><literal>Z</literal></entry>
<entry>Internal-use types</entry>
</row>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType()
with system catalog lookups, as was foreseen to be necessary almost since
their creation. Instead put the information into two new pg_type columns,
typcategory and typispreferred. Add support for setting these when
creating a user-defined base type.
The category column is just a "char" (i.e. a poor man's enum), allowing
a crude form of user extensibility of the category list: just use an
otherwise-unused character. This seems sufficient for foreseen uses,
but we could upgrade to having an actual category catalog someday, if
there proves to be a huge demand for custom type categories.
In this patch I have attempted to hew exactly to the behavior of the
previous hardwired logic, except for introducing new type categories for
arrays, composites, and enums. In particular the default preferred state
for user-defined types remains TRUE. That seems worth revisiting, but it
should be done as a separate patch from introducing the infrastructure.
Likewise, any adjustment of the standard set of categories should be done
separately.
2008-07-30 19:05:05 +02:00
</tbody>
</tgroup>
</table>
2001-11-09 00:44:01 +01:00
</sect1>
2003-10-18 00:38:20 +02:00
2009-02-02 10:49:29 +01:00
<sect1 id="catalog-pg-user-mapping">
<title><structname>pg_user_mapping</structname></title>
<indexterm zone="catalog-pg-user-mapping">
<primary>pg_user_mapping</primary>
</indexterm>
<para>
The catalog <structname>pg_user_mapping</structname> stores
the mappings from local user to remote. Access to this catalog is
restricted from normal users, use the view
<link linkend="view-pg-user-mappings"><structname>pg_user_mappings</structname></link>
instead.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_user_mapping</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2009-02-02 10:49:29 +01:00
<thead>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
2009-02-02 10:49:29 +01:00
</row>
</thead>
<tbody>
2012-12-15 06:42:47 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
2012-12-15 06:42:47 +01:00
</row>
2009-02-02 10:49:29 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>umuser</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2021-02-02 22:15:29 +01:00
OID of the local role being mapped, or zero if the user mapping is public
2020-05-14 05:03:39 +02:00
</para></entry>
2009-02-02 10:49:29 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>umserver</structfield> <type>oid</type>
(references <link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2009-02-02 10:49:29 +01:00
The OID of the foreign server that contains this mapping
2020-05-14 05:03:39 +02:00
</para></entry>
2009-02-02 10:49:29 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>umoptions</structfield> <type>text[]</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
User mapping specific options, as <quote>keyword=value</quote> strings
2020-05-14 05:03:39 +02:00
</para></entry>
2009-02-02 10:49:29 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2000-11-29 21:15:59 +01:00
</chapter>