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>
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>
<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>
The data type of this 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>attstattarget</structfield> <type>int4</type>
</para>
<para>
2001-05-07 02:43:27 +02:00
<structfield>attstattarget</structfield> controls the level of detail
of statistics accumulated for this column 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>.
2001-05-07 02:43:27 +02:00
A zero value indicates that no statistics should be collected.
2002-07-31 19:19:54 +02:00
A negative value says to use the system default statistics target.
2003-04-15 15:23:35 +02:00
The exact meaning of positive values is data type-dependent.
For scalar data types, <structfield>attstattarget</structfield>
2001-05-07 02:43:27 +02:00
is both the target number of <quote>most common values</quote>
2010-08-17 06:37:21 +02:00
to collect, and the target number of histogram bins to create.
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>attndims</structfield> <type>int4</type>
</para>
<para>
2001-11-03 22:42:47 +01:00
Number of dimensions, if the column is an array type; otherwise 0.
(Presently, the number of dimensions of an array is not enforced,
2017-10-09 03:44:17 +02:00
so any nonzero value effectively means <quote>it's an array</quote>.)
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>
<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>
<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">
<structfield>attalign</structfield> <type>char</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
A copy of <literal>pg_type.typalign</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>attnotnull</structfield> <type>bool</type>
</para>
<para>
2014-10-11 23:23:57 +02:00
This represents a not-null constraint.
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">
<structfield>attinhcount</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
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>
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>attcollation</structfield> <type>oid</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2011-03-08 23:10:34 +01:00
The defined collation of the column, or zero if the column is
2011-05-19 00:14:45 +02:00
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>
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>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
2011-07-04 04:12:14 +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>
2015-10-04 02:19:57 +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
2017-04-21 21:51:57 +02:00
the same as that specified by RFC 5803.
</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">
<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>
</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>
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_class</structname> catalogs tables and most
2000-11-29 21:15:59 +01:00
everything else that has columns or is 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
<quote>relations</quote>. Not all columns are meaningful for all relation
types.
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,
Don't create pg_type entries for sequences or toast tables.
Commit f7f70d5e2 left one inconsistency behind: we're still creating
pg_type entries for the composite types of sequences and toast tables,
but not arrays over those composites. But there seems precious little
reason to have named composite types for toast tables, and not much more
to have them for sequences (especially given the thought that sequences
may someday not be standalone relations at all).
So, let's close that inconsistency by removing these composite types,
rather than adding arrays for them. This buys back a little bit of
the initial pg_type bloat added by the previous patch, and could be
a significant savings in a large database with many toast tables.
Aside from a small logic rearrangement in heap_create_with_catalog,
this patch mostly needs to clean up some places that were assuming that
pg_class.reltype always has a valid value. Those are really pre-existing
bugs, given that it's documented otherwise; notably, the plpgsql changes
fix code that gives "cache lookup failed for type 0" on indexes today.
But none of these seem interesting enough to back-patch.
Also, remove the pg_dump/pg_upgrade infrastructure for propagating
a toast table's pg_type OID into the new database, since we no longer
need that.
Discussion: https://postgr.es/m/761F1389-C6A8-4C15-80CE-950C961F5341@gmail.com
2020-07-07 21:43:22 +02: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>
2010-08-25 20:18:41 +02:00
For typed tables, the OID of the underlying composite type,
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>
2019-06-20 06:04:56 +02:00
If this is a table or an index, the access method used (heap,
B-tree, hash, etc.)
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>relfilenode</structfield> <type>oid</type>
</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>
2004-06-18 08:14:31 +02: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.)
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>
2006-11-12 07:25:37 +01:00
OID of the TOAST table associated with this table, 0 if none. The
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>
2017-10-09 03:44:17 +02:00
<literal>p</literal> = permanent table, <literal>u</literal> = unlogged table,
<literal>t</literal> = temporary table
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>
2018-10-22 08:26:28 +02:00
True if table or index has (or once had) any inheritance children
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>
2015-01-29 03:47:15 +01: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>
2015-10-05 03:05:08 +02:00
True if row level security (when enabled) will also apply to table owner; see
<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;
otherwise 0. That state is only visible internally; this field should
never contain anything other than 0 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">
<structfield>collcollate</structfield> <type>name</type>
</para>
<para>
<symbol>LC_COLLATE</symbol> for this collation object
</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>collctype</structfield> <type>name</type>
</para>
<para>
<symbol>LC_CTYPE</symbol> for this collation object
</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>collversion</structfield> <type>text</type>
</para>
<para>
2017-03-23 20:25:34 +01:00
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.
2020-05-14 05:03:39 +02:00
</para></entry>
2017-03-23 20:25:34 +01:00
</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>
2009-12-07 06:22:23 +01:00
The catalog <structname>pg_constraint</structname> stores check, primary
key, unique, foreign key, and exclusion constraints on tables.
(Column constraints are not treated specially. Every column constraint is
equivalent to some table constraint.)
2020-09-03 13:15:53 +02:00
Not-null constraints are represented in the
<link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>
2009-12-07 06:22:23 +01:00
catalog, not here.
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,
<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?
Currently, can only be false for foreign keys and CHECK constraints
</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>
The table this constraint is on; 0 if not a table 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>contypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The domain this constraint is on; 0 if not a domain constraint
</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
key, foreign key, or exclusion constraint; else 0
</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>
The corresponding constraint in the parent partitioned table,
if this is a constraint in a partition; else 0
</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>
If a foreign key, the referenced table; else 0
</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">
<structfield>coninhcount</structfield> <type>int4</type>
</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>
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>
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>
Source encoding ID
</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>
Destination encoding ID
</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
(<function>pg_encoding_to_char()</function> can translate
this number to the encoding name)
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
2008-09-23 11:20:39 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datcollate</structfield> <type>name</type>
</para>
<para>
LC_COLLATE for this database
</para></entry>
2008-09-23 11:20:39 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datctype</structfield> <type>name</type>
</para>
<para>
LC_CTYPE for this database
</para></entry>
2008-09-23 11:20:39 +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>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>
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
2010-08-17 06:37:21 +02:00
to this database. -1 means no limit.
2020-05-14 05:03:39 +02:00
</para></entry>
2005-07-31 19:19:22 +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>datlastsysoid</structfield> <type>oid</type>
</para>
<para>
2001-08-26 18:56:03 +02:00
Last system OID in the database; useful
2000-11-29 21:15:59 +01:00
particularly to <application>pg_dump</application>
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01: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
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,
or 0 if none
</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
<structfield>defaclnamespace</structfield> = 0, 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>
The OID of the system catalog the dependent 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>objid</structfield> <type>oid</type>
(references any OID column)
</para>
<para>
The OID of the specific dependent 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>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
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_PIN</symbol> (<literal>p</literal>)</term>
2003-04-15 15:23:35 +02:00
<listitem>
<para>
There is no dependent object; this type of entry is a signal
that the system itself depends on the referenced object, and so
that object must never be deleted. Entries of this type are
2020-09-03 13:15:53 +02:00
created only by <application>initdb</application>. The columns for the
2003-04-15 15:23:35 +02:00
dependent object contain zeroes.
</para>
</listitem>
</varlistentry>
</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>
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>
<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>
2007-09-20 19:56:33 +02:00
event horizon, because the table may contain broken HOT chains with
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
indicate which table columns this index indexes. For example a value
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>
Indexes can not have multiple inheritance, since they can only inherit
when using declarative partitioning.
2020-05-14 05:03:39 +02:00
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</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
2006-11-12 07:25:37 +01:00
language
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>
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
Type of the left operand (0 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>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
</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>
Commutator of this operator, if any
</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>
Negator of this operator, if any
</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
</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
</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
</para></entry>
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
2002-09-24 23:26:44 +02:00
<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
Unused columns contain zeroes. For example, <structfield>oprleft</structfield>
2006-01-16 19:15:31 +01:00
is zero for a prefix operator.
2002-09-24 23:26:44 +02:00
</para>
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>
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>
The number of columns in partition key
</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
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>
2015-01-29 03:47:15 +01: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>
The roles to which the policy is applied
</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>
Optional planner support function for this function
(see <xref linkend="xfunc-optimization"/>)
</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>
2005-03-29 21:44:23 +02:00
An array with 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
2017-10-09 03:44:17 +02:00
<literal>VARIADIC</literal> arguments), and thus represents
2010-08-17 06:37:21 +02:00
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>
2005-03-29 21:44:23 +02:00
An array with 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>
An array with the modes of the function arguments, encoded as
<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>
An array with the names of the function arguments.
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>
</para>
<para>
2015-04-26 16:33:14 +02:00
Data type OIDs for which to apply transforms.
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>
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
2005-01-06 00:42:03 +01:00
name (link symbol). For all other currently-known language types,
2003-04-15 15:23:35 +02:00
<structfield>prosrc</structfield> contains the function's source
text. <structfield>probin</structfield> is unused except for
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>
<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>
</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>
<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>
OID of the collation used for range comparisons, or 0 if none
</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,
or 0 if none
</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
values as <type>double precision</type>, or 0 if none
</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>
The OID of the system catalog the dependent object is in
</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>
The OID of the specific dependent object
</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>
2005-07-07 22:40:02 +02:00
<varlistentry>
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_PIN</symbol> (<literal>p</literal>)</term>
2005-07-07 22:40:02 +02:00
<listitem>
<para>
There is no dependent object; this type of entry is a signal
that the system itself depends on the referenced object, and so
that object must never be deleted. Entries of this type are
2020-09-03 13:15:53 +02:00
created only by <application>initdb</application>. The columns for the
2005-07-07 22:40:02 +02:00
dependent object contain zeroes.
</para>
</listitem>
</varlistentry>
</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
2005-07-07 22:40:02 +02:00
that the current definition only supports roles as referenced objects.
</para>
</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.
2009-12-29 21:11:45 +01:00
If the table has inheritance children, 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>
If true, the stats include inheritance child columns, not just the
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.
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>
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">
<structfield>stxstattarget</structfield> <type>int4</type>
</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.
2020-09-21 18:43:42 +02:00
A negative value says to use the maximum of the statistics targets of
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>stxkeys</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
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
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>stxkind</structfield> <type>char[]</type>
</para>
<para>
An array containing codes for the enabled statistic kinds;
valid values are:
<literal>d</literal> for n-distinct statistics,
<literal>f</literal> for functional dependency statistics, and
<literal>m</literal> for most common values (MCV) list statistics
</para></entry>
2017-05-15 01:15:52 +02:00
</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>
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 statistic object containing the definition for this data
</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>
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>
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>
<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>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<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>
</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,
<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
if this operation is not supported.
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
stored if this operation is not supported.
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>
2020-02-27 17:23:33 +01:00
Parent trigger that this trigger is cloned from, zero if not a clone;
this happens when partitions are created or attached to a partitioned
table.
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
</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
</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>
2020-09-03 13:15:53 +02:00
The <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> entry associated with the trigger, if any
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>
OID of the parser's headline 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>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>
OID of the template's initialization 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>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,
2011-11-19 00:23:55 +01:00
<literal>p</literal> for a pseudo-type, or
<literal>r</literal> for a range 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>
<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>
2000-11-29 21:15:59 +01:00
If <structfield>typelem</structfield> is not 0 then it
identifies another row in <structname>pg_type</structname>.
The current type can then be subscripted like an array yielding
2001-11-03 22:42:47 +01:00
values of type <structfield>typelem</structfield>. A
<quote>true</quote> array type is variable length
(<structfield>typlen</structfield> = -1),
but some fixed-length (<structfield>typlen</structfield> > 0) types
also have nonzero <structfield>typelem</structfield>, for example
2005-03-29 02:17:27 +02:00
<type>name</type> and <type>point</type>.
2001-11-03 22:42:47 +01:00
If a fixed-length type has a <structfield>typelem</structfield> then
2003-04-15 15:23:35 +02:00
its internal representation must be some number of values of the
2002-03-22 20:20:45 +01:00
<structfield>typelem</structfield> data type with no other data.
2001-11-03 22:42:47 +01:00
Variable-length array types have a header defined by the array
2010-08-17 06:37:21 +02:00
subroutines.
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>
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
If <structfield>typarray</structfield> is not 0 then it
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>
Input conversion function (binary format), or 0 if none
</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>
Output conversion function (binary format), or 0 if none
</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>
Type modifier input function, or 0 if type does not support modifiers
</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>
Type modifier output function, or 0 to use the standard format
</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>
2020-09-03 13:15:53 +02:00
Custom <xref linkend="sql-analyze"/> function, or 0 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>
</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>
OID of the local role being mapped, 0 if the user mapping is public
</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>
2003-10-18 00:38:20 +02:00
<sect1 id="views-overview">
<title>System Views</title>
<para>
In addition to the system catalogs, <productname>PostgreSQL</productname>
2005-01-06 00:42:03 +01:00
provides a number of built-in views. Some system views provide convenient
access to some commonly used queries on the system catalogs. Other views
provide access to internal server state.
2003-10-18 00:38:20 +02:00
</para>
<para>
2017-11-23 15:39:47 +01:00
The information schema (<xref linkend="information-schema"/>) provides
2003-10-18 00:38:20 +02:00
an alternative set of views which overlap the functionality of the system
views. Since the information schema is SQL-standard whereas the views
described here are <productname>PostgreSQL</productname>-specific,
it's usually better to use the information schema if it provides all
the information you need.
</para>
2005-01-06 00:42:03 +01:00
<para>
2017-11-23 15:39:47 +01:00
<xref linkend="view-table"/> lists the system views described here.
2005-01-06 00:42:03 +01:00
More detailed documentation of each view follows below.
There are some additional views that provide access to the results of
the statistics collector; they are described in <xref
2017-11-23 15:39:47 +01:00
linkend="monitoring-stats-views-table"/>.
2005-01-06 00:42:03 +01:00
</para>
2003-10-18 00:38:20 +02:00
<para>
Except where noted, all the views described here are read-only.
</para>
<table id="view-table">
<title>System Views</title>
<tgroup cols="2">
<thead>
<row>
<entry>View Name</entry>
<entry>Purpose</entry>
</row>
</thead>
<tbody>
2011-02-08 22:08:41 +01:00
<row>
<entry><link linkend="view-pg-available-extensions"><structname>pg_available_extensions</structname></link></entry>
<entry>available extensions</entry>
</row>
2011-02-14 22:07:00 +01:00
<row>
<entry><link linkend="view-pg-available-extension-versions"><structname>pg_available_extension_versions</structname></link></entry>
<entry>available versions of extensions</entry>
</row>
2020-08-19 08:34:43 +02:00
<row>
<entry><link linkend="view-pg-backend-memory-contexts"><structname>pg_backend_memory_contexts</structname></link></entry>
<entry>backend memory contexts</entry>
</row>
2016-02-17 18:12:06 +01:00
<row>
<entry><link linkend="view-pg-config"><structname>pg_config</structname></link></entry>
<entry>compile-time configuration parameters</entry>
</row>
2006-01-18 07:49:30 +01:00
<row>
<entry><link linkend="view-pg-cursors"><structname>pg_cursors</structname></link></entry>
<entry>open cursors</entry>
</row>
2015-06-12 05:59:29 +02:00
<row>
<entry><link linkend="view-pg-file-settings"><structname>pg_file_settings</structname></link></entry>
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
<entry>summary of configuration file contents</entry>
2015-06-12 05:59:29 +02:00
</row>
2005-06-28 07:09:14 +02:00
<row>
<entry><link linkend="view-pg-group"><structname>pg_group</structname></link></entry>
<entry>groups of database users</entry>
</row>
2017-01-31 00:00:26 +01:00
<row>
<entry><link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link></entry>
<entry>summary of client authentication configuration file contents</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
<entry><link linkend="view-pg-indexes"><structname>pg_indexes</structname></link></entry>
<entry>indexes</entry>
</row>
<row>
<entry><link linkend="view-pg-locks"><structname>pg_locks</structname></link></entry>
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
<entry>locks currently held or awaited</entry>
2003-10-18 00:38:20 +02:00
</row>
2013-03-06 22:35:59 +01:00
<row>
<entry><link linkend="view-pg-matviews"><structname>pg_matviews</structname></link></entry>
<entry>materialized views</entry>
</row>
2014-10-03 22:31:53 +02:00
<row>
<entry><link linkend="view-pg-policies"><structname>pg_policies</structname></link></entry>
<entry>policies</entry>
</row>
2006-01-08 08:00:27 +01:00
<row>
<entry><link linkend="view-pg-prepared-statements"><structname>pg_prepared_statements</structname></link></entry>
2006-01-16 19:15:31 +01:00
<entry>prepared statements</entry>
2006-01-08 08:00:27 +01:00
</row>
2005-06-18 00:32:51 +02:00
<row>
<entry><link linkend="view-pg-prepared-xacts"><structname>pg_prepared_xacts</structname></link></entry>
2006-01-16 19:15:31 +01:00
<entry>prepared transactions</entry>
2005-06-18 00:32:51 +02:00
</row>
2017-01-19 18:00:00 +01:00
<row>
<entry><link linkend="view-pg-publication-tables"><structname>pg_publication_tables</structname></link></entry>
<entry>publications and their associated tables</entry>
</row>
2016-05-05 18:33:12 +02:00
<row>
<entry><link linkend="view-pg-replication-origin-status"><structname>pg_replication_origin_status</structname></link></entry>
<entry>information about replication origins, including replication progress</entry>
</row>
<row>
<entry><link linkend="view-pg-replication-slots"><structname>pg_replication_slots</structname></link></entry>
<entry>replication slot information</entry>
</row>
2005-06-28 07:09:14 +02:00
<row>
<entry><link linkend="view-pg-roles"><structname>pg_roles</structname></link></entry>
<entry>database roles</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
<entry><link linkend="view-pg-rules"><structname>pg_rules</structname></link></entry>
<entry>rules</entry>
</row>
2010-09-28 02:55:27 +02:00
<row>
<entry><link linkend="view-pg-seclabels"><structname>pg_seclabels</structname></link></entry>
<entry>security labels</entry>
</row>
2016-11-18 18:00:00 +01:00
<row>
<entry><link linkend="view-pg-sequences"><structname>pg_sequences</structname></link></entry>
<entry>sequences</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
<entry><link linkend="view-pg-settings"><structname>pg_settings</structname></link></entry>
<entry>parameter settings</entry>
</row>
2005-06-28 07:09:14 +02:00
<row>
<entry><link linkend="view-pg-shadow"><structname>pg_shadow</structname></link></entry>
<entry>database users</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
2020-05-25 08:18:11 +02:00
<entry><link linkend="view-pg-shmem-allocations"><structname>pg_shmem_allocations</structname></link></entry>
<entry>shared memory allocations</entry>
2003-10-18 00:38:20 +02:00
</row>
2020-01-09 16:59:07 +01:00
<row>
2020-05-25 08:18:11 +02:00
<entry><link linkend="view-pg-stats"><structname>pg_stats</structname></link></entry>
<entry>planner statistics</entry>
2020-01-09 16:59:07 +01:00
</row>
2019-06-13 17:25:04 +02:00
<row>
<entry><link linkend="view-pg-stats-ext"><structname>pg_stats_ext</structname></link></entry>
<entry>extended planner statistics</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
<entry><link linkend="view-pg-tables"><structname>pg_tables</structname></link></entry>
<entry>tables</entry>
</row>
2006-07-25 05:51:23 +02:00
<row>
2006-09-16 22:14:34 +02:00
<entry><link linkend="view-pg-timezone-abbrevs"><structname>pg_timezone_abbrevs</structname></link></entry>
2006-07-25 05:51:23 +02:00
<entry>time zone abbreviations</entry>
</row>
2006-09-16 22:14:34 +02:00
<row>
<entry><link linkend="view-pg-timezone-names"><structname>pg_timezone_names</structname></link></entry>
<entry>time zone names</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
<entry><link linkend="view-pg-user"><structname>pg_user</structname></link></entry>
<entry>database users</entry>
</row>
2010-10-15 01:12:24 +02:00
<row>
<entry><link linkend="view-pg-user-mappings"><structname>pg_user_mappings</structname></link></entry>
<entry>user mappings</entry>
</row>
2003-10-18 00:38:20 +02:00
<row>
<entry><link linkend="view-pg-views"><structname>pg_views</structname></link></entry>
<entry>views</entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
2011-02-08 22:08:41 +01:00
<sect1 id="view-pg-available-extensions">
<title><structname>pg_available_extensions</structname></title>
<indexterm zone="view-pg-available-extensions">
<primary>pg_available_extensions</primary>
</indexterm>
<para>
The <structname>pg_available_extensions</structname> view lists the
2011-03-04 22:08:24 +01:00
extensions that are available for installation.
See also the
2011-02-08 22:08:41 +01:00
<link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>
catalog, which shows the extensions currently installed.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_available_extensions</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>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>name</type>
</para>
<para>
Extension name
</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>default_version</structfield> <type>text</type>
</para>
<para>
Name of default version, or <literal>NULL</literal> if none is
specified
</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>installed_version</structfield> <type>text</type>
</para>
<para>
Currently installed version of the extension,
or <literal>NULL</literal> if not installed
</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>comment</structfield> <type>text</type>
</para>
<para>
Comment string from the extension's control file
</para></entry>
2011-02-14 22:07:00 +01:00
</row>
</tbody>
</tgroup>
</table>
<para>
The <structname>pg_available_extensions</structname> view is read only.
</para>
</sect1>
<sect1 id="view-pg-available-extension-versions">
<title><structname>pg_available_extension_versions</structname></title>
<indexterm zone="view-pg-available-extension-versions">
<primary>pg_available_extension_versions</primary>
</indexterm>
<para>
The <structname>pg_available_extension_versions</structname> view lists the
2011-03-04 22:08:24 +01:00
specific extension versions that are available for installation.
See also the <link
2011-02-14 22:07:00 +01:00
linkend="catalog-pg-extension"><structname>pg_extension</structname></link>
catalog, which shows the extensions currently installed.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_available_extension_versions</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2011-02-14 22:07: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>
2011-02-14 22:07: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>name</structfield> <type>name</type>
</para>
<para>
Extension name
</para></entry>
2011-02-14 22:07:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>version</structfield> <type>text</type>
</para>
<para>
Version name
</para></entry>
2011-02-14 22:07:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>installed</structfield> <type>bool</type>
</para>
<para>
True if this version of this extension is currently
installed
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
2011-03-04 22:08:24 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>superuser</structfield> <type>bool</type>
</para>
<para>
True if only superusers are allowed to install this extension
(but see <structfield>trusted</structfield>)
</para></entry>
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
This patch creates a new extension property, "trusted". An extension
that's marked that way in its control file can be installed by a
non-superuser who has the CREATE privilege on the current database,
even if the extension contains objects that normally would have to be
created by a superuser. The objects within the extension will (by
default) be owned by the bootstrap superuser, but the extension itself
will be owned by the calling user. This allows replicating the old
behavior around trusted procedural languages, without all the
special-case logic in CREATE LANGUAGE. We have, however, chosen to
loosen the rules slightly: formerly, only a database owner could take
advantage of the special case that allowed installation of a trusted
language, but now anyone who has CREATE privilege can do so.
Having done that, we can delete the pg_pltemplate catalog, moving the
knowledge it contained into the extension script files for the various
PLs. This ends up being no change at all for the in-core PLs, but it is
a large step forward for external PLs: they can now have the same ease
of installation as core PLs do. The old "trusted PL" behavior was only
available to PLs that had entries in pg_pltemplate, but now any
extension can be marked trusted if appropriate.
This also removes one of the stumbling blocks for our Python 2 -> 3
migration, since the association of "plpythonu" with Python 2 is no
longer hard-wired into pg_pltemplate's initial contents. Exactly where
we go from here on that front remains to be settled, but one problem
is fixed.
Patch by me, reviewed by Peter Eisentraut, Stephen Frost, and others.
Discussion: https://postgr.es/m/5889.1566415762@sss.pgh.pa.us
2020-01-30 00:42:43 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>trusted</structfield> <type>bool</type>
</para>
<para>
True if the extension can be installed by non-superusers
with appropriate privileges
</para></entry>
2011-03-04 22:08:24 +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>relocatable</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>
2011-02-14 22:07:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schema</structfield> <type>name</type>
</para>
<para>
Name of the schema that the extension must be installed into,
or <literal>NULL</literal> if partially or fully relocatable
</para></entry>
2011-02-14 22:07:00 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>requires</structfield> <type>name[]</type>
</para>
<para>
Names of prerequisite extensions,
or <literal>NULL</literal> if none
</para></entry>
2011-02-14 22:07:00 +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>comment</structfield> <type>text</type>
</para>
<para>
Comment string from the extension's control file
</para></entry>
2011-02-08 22:08:41 +01:00
</row>
</tbody>
</tgroup>
</table>
<para>
2011-02-14 22:07:00 +01:00
The <structname>pg_available_extension_versions</structname> view is read
only.
2011-02-08 22:08:41 +01:00
</para>
</sect1>
2020-08-19 08:34:43 +02:00
<sect1 id="view-pg-backend-memory-contexts">
<title><structname>pg_backend_memory_contexts</structname></title>
<indexterm zone="view-pg-backend-memory-contexts">
<primary>pg_backend_memory_contexts</primary>
</indexterm>
<para>
The view <structname>pg_backend_memory_contexts</structname> displays all
the memory contexts of the server process attached to the current session.
</para>
<para>
<structname>pg_backend_memory_contexts</structname> contains one row
for each memory context.
</para>
<table>
<title><structname>pg_backend_memory_contexts</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>name</structfield> <type>text</type>
</para>
<para>
Name of the memory context
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ident</structfield> <type>text</type>
</para>
<para>
Identification information of the memory context. This field is truncated at 1024 bytes
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>parent</structfield> <type>text</type>
</para>
<para>
Name of the parent of this memory context
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>level</structfield> <type>int4</type>
</para>
<para>
Distance from TopMemoryContext in context tree
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>total_bytes</structfield> <type>int8</type>
</para>
<para>
Total bytes allocated for this memory context
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>total_nblocks</structfield> <type>int8</type>
</para>
<para>
Total number of blocks allocated for this memory context
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>free_bytes</structfield> <type>int8</type>
</para>
<para>
Free space in bytes
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>free_chunks</structfield> <type>int8</type>
</para>
<para>
Total number of free chunks
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>used_bytes</structfield> <type>int8</type>
</para>
<para>
Used space in bytes
</para></entry>
</row>
</tbody>
</tgroup>
</table>
2020-08-26 03:50:02 +02:00
<para>
By default, the <structname>pg_backend_memory_contexts</structname> view can be
read only by superusers.
</para>
2020-08-19 08:34:43 +02:00
</sect1>
2016-02-17 18:12:06 +01:00
<sect1 id="view-pg-config">
<title><structname>pg_config</structname></title>
<indexterm zone="view-pg-config">
<primary>pg_config</primary>
</indexterm>
<para>
The view <structname>pg_config</structname> describes the
compile-time configuration parameters of the currently installed
2017-10-09 03:44:17 +02:00
version of <productname>PostgreSQL</productname>. It is intended, for example, to
2016-02-17 18:12:06 +01:00
be used by software packages that want to interface to
2017-10-09 03:44:17 +02:00
<productname>PostgreSQL</productname> to facilitate finding the required header
2016-02-17 18:12:06 +01:00
files and libraries. It provides the same basic information as the
2017-11-23 15:39:47 +01:00
<xref linkend="app-pgconfig"/> <productname>PostgreSQL</productname> client
2016-05-05 19:27:59 +02:00
application.
2016-02-17 18:12:06 +01:00
</para>
2016-09-24 22:25:35 +02:00
<para>
By default, the <structname>pg_config</structname> view can be read
only by superusers.
</para>
2016-02-17 18:12:06 +01:00
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_config</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2016-02-17 18:12:06 +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-02-17 18:12:06 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
The parameter name
</para></entry>
2016-02-17 18:12:06 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>setting</structfield> <type>text</type>
</para>
<para>
The parameter value
</para></entry>
2016-02-17 18:12:06 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2006-01-18 07:49:30 +01:00
<sect1 id="view-pg-cursors">
<title><structname>pg_cursors</structname></title>
<indexterm zone="view-pg-cursors">
<primary>pg_cursors</primary>
</indexterm>
<para>
The <structname>pg_cursors</structname> view lists the cursors that
are currently available. Cursors can be defined in several ways:
<itemizedlist>
<listitem>
<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
via the <link linkend="sql-declare"><command>DECLARE</command></link>
2006-01-18 07:49:30 +01:00
statement in SQL
</para>
</listitem>
<listitem>
<para>
via the Bind message in the frontend/backend protocol, as
2017-11-23 15:39:47 +01:00
described in <xref linkend="protocol-flow-ext-query"/>
2006-01-18 07:49:30 +01:00
</para>
</listitem>
<listitem>
<para>
via the Server Programming Interface (SPI), as described in
2017-11-23 15:39:47 +01:00
<xref linkend="spi-interface"/>
2006-01-21 20:05:59 +01:00
</para>
</listitem>
2006-01-18 07:49:30 +01:00
</itemizedlist>
The <structname>pg_cursors</structname> view displays cursors
created by any of these means. Cursors only exist for the duration
of the transaction that defines them, unless they have been
declared <literal>WITH HOLD</literal>. Therefore non-holdable
cursors are only present in the view until the end of their
creating transaction.
<note>
<para>
Cursors are used internally to implement some of the components
2017-10-09 03:44:17 +02:00
of <productname>PostgreSQL</productname>, such as procedural languages.
Therefore, the <structname>pg_cursors</structname> view might include cursors
2006-01-18 07:49:30 +01:00
that have not been explicitly created by the user.
</para>
</note>
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_cursors</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2006-01-18 07:49:30 +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-01-18 07:49:30 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
The name of the cursor
</para></entry>
2006-01-18 07:49:30 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>statement</structfield> <type>text</type>
</para>
<para>
The verbatim query string submitted to declare this cursor
</para></entry>
2006-01-18 07:49:30 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>is_holdable</structfield> <type>bool</type>
</para>
<para>
2006-01-18 07:49:30 +01:00
<literal>true</literal> if the cursor is holdable (that is, it
can be accessed after the transaction that declared the cursor
has committed); <literal>false</literal> otherwise
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-18 07:49:30 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>is_binary</structfield> <type>bool</type>
</para>
<para>
2006-01-18 07:49:30 +01:00
<literal>true</literal> if the cursor was declared
<literal>BINARY</literal>; <literal>false</literal>
otherwise
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-18 07:49:30 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>is_scrollable</structfield> <type>bool</type>
</para>
<para>
2017-10-09 03:44:17 +02:00
<literal>true</literal> if the cursor is scrollable (that is, it
2006-01-18 07:49:30 +01:00
allows rows to be retrieved in a nonsequential manner);
<literal>false</literal> otherwise
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-18 07:49:30 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>creation_time</structfield> <type>timestamptz</type>
</para>
<para>
The time at which the cursor was declared
</para></entry>
2006-01-18 07:49:30 +01:00
</row>
</tbody>
</tgroup>
</table>
<para>
The <structname>pg_cursors</structname> view is read only.
</para>
</sect1>
2015-06-12 05:59:29 +02:00
<sect1 id="view-pg-file-settings">
<title><structname>pg_file_settings</structname></title>
<indexterm zone="view-pg-file-settings">
<primary>pg_file_settings</primary>
</indexterm>
<para>
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
The view <structname>pg_file_settings</structname> provides a summary of
the contents of the server's configuration file(s). A row appears in
2017-10-09 03:44:17 +02:00
this view for each <quote>name = value</quote> entry appearing in the files,
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
with annotations indicating whether the value could be applied
successfully. Additional row(s) may appear for problems not linked to
2017-10-09 03:44:17 +02:00
a <quote>name = value</quote> entry, such as syntax errors in the files.
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
</para>
<para>
This view is helpful for checking whether planned changes in the
configuration files will work, or for diagnosing a previous failure.
2017-10-09 03:44:17 +02:00
Note that this view reports on the <emphasis>current</emphasis> contents of the
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
files, not on what was last applied by the server. (The
<link linkend="view-pg-settings"><structname>pg_settings</structname></link>
view is usually sufficient to determine that.)
</para>
<para>
2016-09-24 22:25:35 +02:00
By default, the <structname>pg_file_settings</structname> view can be read
only by superusers.
2015-06-12 05:59:29 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_file_settings</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
2015-06-12 05:59:29 +02:00
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sourcefile</structfield> <type>text</type>
</para>
<para>
Full path name of the configuration file
</para></entry>
</row>
2015-06-12 05:59:29 +02:00
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sourceline</structfield> <type>int4</type>
</para>
<para>
Line number within the configuration file where the entry appears
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seqno</structfield> <type>int4</type>
</para>
<para>
Order in which the entries are processed (1..<replaceable>n</replaceable>)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
Configuration parameter name
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>setting</structfield> <type>text</type>
</para>
<para>
Value to be assigned to the parameter
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>applied</structfield> <type>bool</type>
</para>
<para>
True if the value can be applied successfully
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>error</structfield> <type>text</type>
</para>
<para>
If not null, an error message indicating why this entry could
not be applied
</para></entry>
</row>
</tbody>
</tgroup>
</table>
<para>
If the configuration file contains syntax errors or invalid parameter
names, the server will not attempt to apply any settings from it, and
therefore all the <structfield>applied</structfield> fields will read as false.
In such a case there will be one or more rows with
non-null <structfield>error</structfield> fields indicating the
problem(s). Otherwise, individual settings will be applied if possible.
If an individual setting cannot be applied (e.g., invalid value, or the
setting cannot be changed after server start) it will have an appropriate
message in the <structfield>error</structfield> field. Another way that
an entry might have <structfield>applied</structfield> = false is that it is
overridden by a later entry for the same parameter name; this case is not
considered an error so nothing appears in
the <structfield>error</structfield> field.
2015-06-12 05:59:29 +02:00
</para>
<para>
2017-11-23 15:39:47 +01:00
See <xref linkend="config-setting"/> for more information about the various
Improve design and implementation of pg_file_settings view.
As first committed, this view reported on the file contents as they were
at the last SIGHUP event. That's not as useful as reporting on the current
contents, and what's more, it didn't work right on Windows unless the
current session had serviced at least one SIGHUP. Therefore, arrange to
re-read the files when pg_show_all_settings() is called. This requires
only minor refactoring so that we can pass changeVal = false to
set_config_option() so that it won't actually apply any changes locally.
In addition, add error reporting so that errors that would prevent the
configuration files from being loaded, or would prevent individual settings
from being applied, are visible directly in the view. This makes the view
usable for pre-testing whether edits made in the config files will have the
desired effect, before one actually issues a SIGHUP.
I also added an "applied" column so that it's easy to identify entries that
are superseded by later entries; this was the main use-case for the original
design, but it seemed unnecessarily hard to use for that.
Also fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. However, since the original coding of the pg_file_settings
view depended on such suppression *not* happening, we couldn't have fixed
this issue now without first doing something with pg_file_settings.
Now we suppress duplicates by marking them "ignored" within
ProcessConfigFileInternal, which doesn't hide them in the view.)
Lesser changes include:
Drive the view directly off the ConfigVariable list, instead of making a
basically-equivalent second copy of the data. There's no longer any need
to hang onto the data permanently, anyway.
Convert show_all_file_settings() to do its work in one call and return a
tuplestore; this avoids risks associated with assuming that the GUC state
will hold still over the course of query execution. (I think there were
probably latent bugs here, though you might need something like a cursor
on the view to expose them.)
Arrange to run SIGHUP processing in a short-lived memory context, to
forestall process-lifespan memory leaks. (There is one known leak in this
code, in ProcessConfigDirectory; it seems minor enough to not be worth
back-patching a specific fix for.)
Remove mistaken assignment to ConfigFileLineno that caused line counting
after an include_dir directive to be completely wrong.
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
2015-06-29 00:06:14 +02:00
ways to change run-time parameters.
2015-06-12 05:59:29 +02:00
</para>
</sect1>
2005-06-28 07:09:14 +02:00
<sect1 id="view-pg-group">
<title><structname>pg_group</structname></title>
<indexterm zone="view-pg-group">
<primary>pg_group</primary>
</indexterm>
<para>
The view <structname>pg_group</structname> exists for backwards
compatibility: it emulates a catalog that existed in
<productname>PostgreSQL</productname> before version 8.1.
It shows the names and members of all roles that are marked as not
2017-10-09 03:44:17 +02:00
<structfield>rolcanlogin</structfield>, which is an approximation to the set
2005-06-28 07:09:14 +02:00
of roles that are being used as groups.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_group</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">
<structfield>groname</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
Name of the group
</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>grosysid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of this group
</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>grolist</structfield> <type>oid[]</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
An array containing the IDs of the roles in this group
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2017-01-31 00:00:26 +01:00
<sect1 id="view-pg-hba-file-rules">
<title><structname>pg_hba_file_rules</structname></title>
<indexterm zone="view-pg-hba-file-rules">
<primary>pg_hba_file_rules</primary>
</indexterm>
<para>
The view <structname>pg_hba_file_rules</structname> provides a summary of
2020-09-03 13:15:53 +02:00
the contents of the client authentication configuration file,
<link linkend="auth-pg-hba-conf"><filename>pg_hba.conf</filename></link>.
A row appears in this view for each
2017-01-31 00:00:26 +01:00
non-empty, non-comment line in the file, with annotations indicating
whether the rule could be applied successfully.
</para>
<para>
This view can be helpful for checking whether planned changes in the
authentication configuration file will work, or for diagnosing a previous
2017-10-09 03:44:17 +02:00
failure. Note that this view reports on the <emphasis>current</emphasis> contents
2017-01-31 00:00:26 +01:00
of the file, not on what was last loaded by the server.
</para>
<para>
By default, the <structname>pg_hba_file_rules</structname> view can be read
only by superusers.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_hba_file_rules</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<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>line_number</structfield> <type>int4</type>
</para>
<para>
Line number of this rule in <filename>pg_hba.conf</filename>
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>type</structfield> <type>text</type>
</para>
<para>
Type of connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>database</structfield> <type>text[]</type>
</para>
<para>
List of database name(s) to which this rule applies
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>user_name</structfield> <type>text[]</type>
</para>
<para>
List of user and group name(s) to which this rule applies
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>address</structfield> <type>text</type>
</para>
<para>
Host name or IP address, or one
of <literal>all</literal>, <literal>samehost</literal>,
or <literal>samenet</literal>, or null for local connections
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>netmask</structfield> <type>text</type>
</para>
<para>
IP address mask, or null if not applicable
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>auth_method</structfield> <type>text</type>
</para>
<para>
Authentication method
</para></entry>
</row>
2017-01-31 00:00:26 +01:00
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>options</structfield> <type>text[]</type>
</para>
<para>
Options specified for authentication method, if any
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>error</structfield> <type>text</type>
</para>
<para>
If not null, an error message indicating why this
line could not be processed
</para></entry>
</row>
</tbody>
</tgroup>
2017-01-31 00:00:26 +01:00
</table>
<para>
Usually, a row reflecting an incorrect entry will have values for only
2017-10-09 03:44:17 +02:00
the <structfield>line_number</structfield> and <structfield>error</structfield> fields.
2017-01-31 00:00:26 +01:00
</para>
<para>
2017-11-23 15:39:47 +01:00
See <xref linkend="client-authentication"/> for more information about
2017-01-31 00:00:26 +01:00
client authentication configuration.
</para>
</sect1>
2003-10-18 00:38:20 +02:00
<sect1 id="view-pg-indexes">
<title><structname>pg_indexes</structname></title>
<indexterm zone="view-pg-indexes">
<primary>pg_indexes</primary>
</indexterm>
<para>
The view <structname>pg_indexes</structname> provides access to
useful information about each index in the database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_indexes</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table and index
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table the index is for
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexname</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of index
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2004-10-11 19:24:41 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablespace</structfield> <type>name</type>
(references <link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.<structfield>spcname</structfield>)
</para>
<para>
Name of tablespace containing index (null if default for database)
</para></entry>
2004-10-11 19:24:41 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexdef</structfield> <type>text</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
Index definition (a reconstructed <xref linkend="sql-createindex"/>
2020-05-14 05:03:39 +02:00
command)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="view-pg-locks">
<title><structname>pg_locks</structname></title>
<indexterm zone="view-pg-locks">
<primary>pg_locks</primary>
</indexterm>
<para>
The view <structname>pg_locks</structname> provides access to
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
information about the locks held by active processes within the
2017-11-23 15:39:47 +01:00
database server. See <xref linkend="mvcc"/> for more discussion
2003-10-18 00:38:20 +02:00
of locking.
</para>
<para>
<structname>pg_locks</structname> contains one row per active lockable
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
object, requested lock mode, and relevant process. Thus, the same
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
lockable object might
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
appear many times, if multiple processes are holding or waiting
2003-10-18 00:38:20 +02:00
for locks on it. However, an object that currently has no locks on it
2005-05-17 23:46:11 +02:00
will not appear at all.
2003-10-18 00:38:20 +02:00
</para>
<para>
2005-05-17 23:46:11 +02:00
There are several distinct types of lockable objects:
whole relations (e.g., tables), individual pages of relations,
individual tuples of relations,
2007-09-05 20:10:48 +02:00
transaction IDs (both virtual and permanent IDs),
2005-05-17 23:46:11 +02:00
and general database objects (identified by class OID and object OID,
2020-09-03 13:15:53 +02:00
in the same way as in <link linkend="catalog-pg-description"><structname>pg_description</structname></link> or
<link linkend="catalog-pg-depend"><structname>pg_depend</structname></link>). Also, the right to extend a
2020-08-15 19:15:53 +02:00
relation is represented as a separate lockable object, as is the right to
update <structname>pg_database</structname>.<structfield>datfrozenxid</structfield>.
2017-10-09 03:44:17 +02:00
Also, <quote>advisory</quote> locks can be taken on numbers that have
2011-11-28 19:51:58 +01:00
user-defined meanings.
2003-10-18 00:38:20 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_locks</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>locktype</structfield> <type>text</type>
</para>
<para>
2010-08-17 06:37:21 +02:00
Type of the lockable object:
2017-10-09 03:44:17 +02:00
<literal>relation</literal>,
<literal>extend</literal>,
2020-08-15 19:15:53 +02:00
<literal>frozenid</literal>,
2017-10-09 03:44:17 +02:00
<literal>page</literal>,
<literal>tuple</literal>,
<literal>transactionid</literal>,
<literal>virtualxid</literal>,
2020-05-16 03:47:21 +02:00
<literal>spectoken</literal>,
2017-10-09 03:44:17 +02:00
<literal>object</literal>,
<literal>userlock</literal>, or
2020-05-14 05:36:58 +02:00
<literal>advisory</literal>.
(See also <xref linkend="wait-event-lock-table"/>.)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>database</structfield> <type>oid</type>
(references <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2011-07-15 19:12:36 +02:00
OID of the database in which the lock target exists, or
zero if the target is a shared object, or
null if the target is a transaction ID
2020-05-14 05:03:39 +02:00
</para></entry>
2005-05-17 23:46:11 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-05-17 23:46:11 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relation</structfield> <type>oid</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2011-07-15 19:12:36 +02:00
OID of the relation targeted by the lock, or null if the target is not
a relation or part of a relation
2020-05-14 05:03:39 +02:00
</para></entry>
2005-05-17 23:46:11 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-05-17 23:46:11 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>page</structfield> <type>int4</type>
</para>
<para>
2011-07-15 19:12:36 +02:00
Page number targeted by the lock within the relation,
or null if the target is not a relation page or tuple
2020-05-14 05:03:39 +02:00
</para></entry>
2005-05-17 23:46:11 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-05-17 23:46:11 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tuple</structfield> <type>int2</type>
</para>
<para>
2011-07-15 19:12:36 +02:00
Tuple number targeted by the lock within the page,
or null if the target is not a tuple
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2007-09-05 20:10:48 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>virtualxid</structfield> <type>text</type>
</para>
<para>
2011-07-15 19:12:36 +02:00
Virtual ID of the transaction targeted by the lock,
or null if the target is not a virtual transaction ID
2020-05-14 05:03:39 +02:00
</para></entry>
2007-09-05 20:10:48 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>transactionid</structfield> <type>xid</type>
</para>
<para>
2011-07-15 19:12:36 +02:00
ID of the transaction targeted by the lock,
or null if the target is not a transaction ID
2020-05-14 05:03:39 +02:00
</para></entry>
2005-05-17 23:46:11 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-05-17 23:46:11 +02:00
<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>
2011-07-15 19:12:36 +02:00
OID of the system catalog containing the lock target, or null if the
target is not a general database object
2020-05-14 05:03:39 +02:00
</para></entry>
2005-05-17 23:46:11 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-05-17 23:46:11 +02:00
<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>
2011-07-15 19:12:36 +02:00
OID of the lock target within its system catalog, or null if the
2011-11-28 19:51:58 +01:00
target is not a general database object
2020-05-14 05:03:39 +02:00
</para></entry>
2005-05-17 23:46:11 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-05-17 23:46:11 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objsubid</structfield> <type>int2</type>
</para>
<para>
2011-07-15 19:12:36 +02:00
Column number targeted by the lock (the
2017-10-09 03:44:17 +02:00
<structfield>classid</structfield> and <structfield>objid</structfield> refer to the
2011-07-15 19:12:36 +02:00
table itself),
or zero if the target is some other general database object,
or null if the target is not a general database object
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-06-18 21:33:42 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>virtualtransaction</structfield> <type>text</type>
</para>
<para>
2007-09-05 20:10:48 +02:00
Virtual ID of the transaction that is holding or awaiting this lock
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-18 21:33:42 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>int4</type>
</para>
<para>
2005-06-18 00:32:51 +02:00
Process ID of the server process holding or awaiting this
2011-11-28 19:51:58 +01:00
lock, or null if the lock is held by a prepared transaction
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>mode</structfield> <type>text</type>
</para>
<para>
Name of the lock mode held or desired by this process (see <xref linkend="locking-tables"/> and <xref linkend="xact-serializable"/>)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>granted</structfield> <type>bool</type>
</para>
<para>
True if lock is held, false if lock is awaited
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2011-05-29 01:52:00 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>fastpath</structfield> <type>bool</type>
</para>
<para>
True if lock was taken via fast path, false if taken via main
lock table
</para></entry>
2011-05-29 01:52:00 +02:00
</row>
2003-10-18 00:38:20 +02:00
</tbody>
</tgroup>
</table>
<para>
<structfield>granted</structfield> is true in a row representing a lock
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
held by the indicated process. False indicates that this process is
currently waiting to acquire this lock, which implies that at least one
other process is holding or waiting for a conflicting lock mode on the same
lockable object. The waiting process will sleep until the other lock is
released (or a deadlock situation is detected). A single process can be
waiting to acquire at most one lock at a time.
2003-10-18 00:38:20 +02:00
</para>
<para>
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
Throughout running a transaction, a server process holds an exclusive lock
on the transaction's virtual transaction ID. If a permanent ID is assigned
to the transaction (which normally happens only if the transaction changes
the state of the database), it also holds an exclusive lock on the
transaction's permanent transaction ID until it ends. When a process finds
it necessary to wait specifically for another transaction to end, it does
so by attempting to acquire share lock on the other transaction's ID
(either virtual or permanent ID depending on the situation). That will
succeed only when the other transaction terminates and releases its locks.
2003-10-18 00:38:20 +02:00
</para>
2005-05-17 23:46:11 +02:00
<para>
Although tuples are a lockable type of object,
information about row-level locks is stored on disk, not in memory,
and therefore row-level locks normally do not appear in this view.
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
If a process is waiting for a
2005-05-17 23:46:11 +02:00
row-level lock, it will usually appear in the view as waiting for the
2007-09-05 20:10:48 +02:00
permanent transaction ID of the current holder of that row lock.
2005-05-17 23:46:11 +02:00
</para>
<para>
2006-09-23 01:20:14 +02:00
Advisory locks can be acquired on keys consisting of either a single
2011-11-28 19:51:58 +01:00
<type>bigint</type> value or two integer values.
A <type>bigint</type> key is displayed with its
2017-10-09 03:44:17 +02:00
high-order half in the <structfield>classid</structfield> column, its low-order half
in the <structfield>objid</structfield> column, and <structfield>objsubid</structfield> equal
2012-08-28 04:36:37 +02:00
to 1. The original <type>bigint</type> value can be reassembled with the
2012-08-28 18:17:11 +02:00
expression <literal>(classid::bigint << 32) |
objid::bigint</literal>. Integer keys are displayed with the
2012-08-28 04:36:37 +02:00
first key in the
2017-10-09 03:44:17 +02:00
<structfield>classid</structfield> column, the second key in the <structfield>objid</structfield>
column, and <structfield>objsubid</structfield> equal to 2. The actual meaning of
2006-09-23 01:20:14 +02:00
the keys is up to the user. Advisory locks are local to each database,
2017-10-09 03:44:17 +02:00
so the <structfield>database</structfield> column is meaningful for an advisory lock.
2005-05-17 23:46:11 +02:00
</para>
2003-10-18 00:38:20 +02:00
<para>
<structname>pg_locks</structname> provides a global view of all locks
in the database cluster, not only those relevant to the current database.
Although its <structfield>relation</structfield> column can be joined
2020-09-03 13:15:53 +02:00
against <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield> to identify locked
2003-10-18 00:38:20 +02:00
relations, this will only work correctly for relations in the current
database (those for which the <structfield>database</structfield> column
is either the current database's OID or zero).
</para>
<para>
2007-09-05 20:10:48 +02:00
The <structfield>pid</structfield> column can be joined to the
2020-05-29 10:14:33 +02:00
<structfield>pid</structfield> column of the
<link linkend="monitoring-pg-stat-activity-view">
<structname>pg_stat_activity</structname></link>
2014-04-03 20:18:25 +02:00
view to get more
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
information on the session holding or awaiting each lock,
2014-04-03 20:18:25 +02:00
for example
<programlisting>
SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa
ON pl.pid = psa.pid;
</programlisting>
2005-06-18 21:33:42 +02:00
Also, if you are using prepared transactions, the
2017-10-09 03:44:17 +02:00
<structfield>virtualtransaction</structfield> column can be joined to the
2014-04-03 20:18:25 +02:00
<structfield>transaction</structfield> column of the <link
linkend="view-pg-prepared-xacts"><structname>pg_prepared_xacts</structname></link>
view to get more information on prepared transactions that hold locks.
2005-06-18 21:33:42 +02:00
(A prepared transaction can never be waiting for a lock,
but it continues to hold the locks it acquired while running.)
2014-04-03 20:18:25 +02:00
For example:
<programlisting>
SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
ON pl.virtualtransaction = '-1/' || ppx.transaction;
</programlisting>
2003-10-18 00:38:20 +02:00
</para>
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
<para>
While it is possible to obtain information about which processes block
which other processes by joining <structname>pg_locks</structname> against
itself, this is very difficult to get right in detail. Such a query would
have to encode knowledge about which lock modes conflict with which
others. Worse, the <structname>pg_locks</structname> view does not expose
information about which processes are ahead of which others in lock wait
queues, nor information about which processes are parallel workers running
on behalf of which other client sessions. It is better to use
2017-10-09 03:44:17 +02:00
the <function>pg_blocking_pids()</function> function
2017-11-23 15:39:47 +01:00
(see <xref linkend="functions-info-session-table"/>) to identify which
Create a function to reliably identify which sessions block which others.
This patch introduces "pg_blocking_pids(int) returns int[]", which returns
the PIDs of any sessions that are blocking the session with the given PID.
Historically people have obtained such information using a self-join on
the pg_locks view, but it's unreasonably tedious to do it that way with any
modicum of correctness, and the addition of parallel queries has pretty
much broken that approach altogether. (Given some more columns in the view
than there are today, you could imagine handling parallel-query cases with
a 4-way join; but ugh.)
The new function has the following behaviors that are painful or impossible
to get right via pg_locks:
1. Correctly understands which lock modes block which other ones.
2. In soft-block situations (two processes both waiting for conflicting lock
modes), only the one that's in front in the wait queue is reported to
block the other.
3. In parallel-query cases, reports all sessions blocking any member of
the given PID's lock group, and reports a session by naming its leader
process's PID, which will be the pg_backend_pid() value visible to
clients.
The motivation for doing this right now is mostly to fix the isolation
tests. Commit 38f8bdcac4982215beb9f65a19debecaf22fd470 lobotomized
isolationtester's is-it-waiting query by removing its ability to recognize
nonconflicting lock modes, as a crude workaround for the inability to
handle soft-block situations properly. But even without the lock mode
tests, the old query was excessively slow, particularly in
CLOBBER_CACHE_ALWAYS builds; some of our buildfarm animals fail the new
deadlock-hard test because the deadlock timeout elapses before they can
probe the waiting status of all eight sessions. Replacing the pg_locks
self-join with use of pg_blocking_pids() is not only much more correct, but
a lot faster: I measure it at about 9X faster in a typical dev build with
Asserts, and 3X faster in CLOBBER_CACHE_ALWAYS builds. That should provide
enough headroom for the slower CLOBBER_CACHE_ALWAYS animals to pass the
test, without having to lengthen deadlock_timeout yet more and thus slow
down the test for everyone else.
2016-02-22 20:31:43 +01:00
process(es) a waiting process is blocked behind.
</para>
2011-11-28 19:51:58 +01:00
<para>
The <structname>pg_locks</structname> view displays data from both the
regular lock manager and the predicate lock manager, which are
separate systems; in addition, the regular lock manager subdivides its
2017-10-09 03:44:17 +02:00
locks into regular and <firstterm>fast-path</firstterm> locks.
2011-11-28 19:51:58 +01:00
This data is not guaranteed to be entirely consistent.
When the view is queried,
2017-10-09 03:44:17 +02:00
data on fast-path locks (with <structfield>fastpath</structfield> = <literal>true</literal>)
2011-11-28 19:51:58 +01:00
is gathered from each backend one at a time, without freezing the state of
the entire lock manager, so it is possible for locks to be taken or
released while information is gathered. Note, however, that these locks are
known not to conflict with any other lock currently in place. After
all backends have been queried for fast-path locks, the remainder of the
regular lock manager is locked as a unit, and a consistent snapshot of all
remaining locks is collected as an atomic action. After unlocking the
regular lock manager, the predicate lock manager is similarly locked and all
predicate locks are collected as an atomic action. Thus, with the exception
of fast-path locks, each lock manager will deliver a consistent set of
results, but as we do not lock both lock managers simultaneously, it is
possible for locks to be taken or released after we interrogate the regular
lock manager and before we interrogate the predicate lock manager.
</para>
<para>
Locking the regular and/or predicate lock manager could have some
impact on database performance if this view is very frequently accessed.
The locks are held only for the minimum amount of time necessary to
obtain data from the lock managers, but this does not completely eliminate
the possibility of a performance impact.
</para>
2003-10-18 00:38:20 +02:00
</sect1>
2013-03-06 22:35:59 +01:00
<sect1 id="view-pg-matviews">
<title><structname>pg_matviews</structname></title>
<indexterm zone="view-pg-matviews">
<primary>pg_matviews</primary>
</indexterm>
<indexterm zone="view-pg-matviews">
<primary>materialized views</primary>
</indexterm>
<para>
The view <structname>pg_matviews</structname> provides access to
useful information about each materialized view in the database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_matviews</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2013-03-06 22:35: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>
2013-03-06 22:35:59 +01:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing materialized view
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>matviewname</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of materialized view
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>matviewowner</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
Name of materialized view's owner
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablespace</structfield> <type>name</type>
(references <link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.<structfield>spcname</structfield>)
</para>
<para>
Name of tablespace containing materialized view (null if default for database)
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>hasindexes</structfield> <type>bool</type>
</para>
<para>
True if materialized view has (or recently had) any indexes
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ispopulated</structfield> <type>bool</type>
</para>
<para>
True if materialized view is currently populated
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
2020-05-14 05:03:39 +02:00
2013-03-06 22:35:59 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>definition</structfield> <type>text</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
Materialized view definition (a reconstructed <xref linkend="sql-select"/> query)
2020-05-14 05:03:39 +02:00
</para></entry>
2013-03-06 22:35:59 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2014-10-03 22:31:53 +02:00
<sect1 id="view-pg-policies">
<title><structname>pg_policies</structname></title>
<indexterm zone="view-pg-policies">
<primary>pg_policies</primary>
</indexterm>
<para>
The view <structname>pg_policies</structname> provides access to
2015-01-24 22:16:22 +01:00
useful information about each row-level security policy in the database.
2014-10-03 22:31:53 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_policies</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2014-10-03 22:31:53 +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>
2014-10-03 22:31:53 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table policy is on
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table policy is on
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>policyname</structfield> <type>name</type>
(references <link linkend="catalog-pg-policy"><structname>pg_policy</structname></link>.<structfield>polname</structfield>)
</para>
<para>
Name of policy
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
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>permissive</structfield> <type>text</type>
</para>
<para>
Is the policy permissive or restrictive?
</para></entry>
2016-12-05 21:50:55 +01:00
</row>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>roles</structfield> <type>name[]</type>
</para>
<para>
The roles to which this policy applies
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cmd</structfield> <type>text</type>
</para>
<para>
The command type to which the policy is applied
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>qual</structfield> <type>text</type>
</para>
<para>
The expression added to the security barrier qualifications for
queries that this policy applies to
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
2020-05-14 05:03:39 +02:00
2014-10-03 22:31:53 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>with_check</structfield> <type>text</type>
</para>
<para>
The expression added to the WITH CHECK qualifications for
queries that attempt to add rows to this table
</para></entry>
2014-10-03 22:31:53 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2006-01-08 08:00:27 +01:00
<sect1 id="view-pg-prepared-statements">
<title><structname>pg_prepared_statements</structname></title>
<indexterm zone="view-pg-prepared-statements">
<primary>pg_prepared_statements</primary>
</indexterm>
<para>
The <structname>pg_prepared_statements</structname> view displays
all the prepared statements that are available in the current
2017-11-23 15:39:47 +01:00
session. See <xref linkend="sql-prepare"/> for more information about prepared
2006-01-08 08:00:27 +01:00
statements.
</para>
<para>
<structname>pg_prepared_statements</structname> contains one row
for each prepared statement. Rows are added to the view when a new
2006-01-16 19:15:31 +01:00
prepared statement is created and removed when a prepared statement
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
is released (for example, via the <link linkend="sql-deallocate"><command>DEALLOCATE</command></link> command).
2006-01-08 08:00:27 +01:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_prepared_statements</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2006-01-08 08:00:27 +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-01-08 08:00:27 +01:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2006-01-08 08:00:27 +01:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
2006-01-16 19:15:31 +01:00
The identifier of the prepared statement
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-08 08:00:27 +01:00
</row>
2020-05-14 05:03:39 +02:00
2006-01-08 08:00:27 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>statement</structfield> <type>text</type>
</para>
<para>
2006-01-08 08:00:27 +01:00
The query string submitted by the client to create this
prepared statement. For prepared statements created via SQL,
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
this is the <command>PREPARE</command> statement submitted by
2006-01-08 08:00:27 +01:00
the client. For prepared statements created via the
frontend/backend protocol, this is the text of the prepared
2010-08-17 06:37:21 +02:00
statement itself.
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-08 08:00:27 +01:00
</row>
2020-05-14 05:03:39 +02:00
2006-01-08 08:00:27 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prepare_time</structfield> <type>timestamptz</type>
</para>
<para>
2006-01-16 19:15:31 +01:00
The time at which the prepared statement was created
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-08 08:00:27 +01:00
</row>
2020-05-14 05:03:39 +02:00
2006-01-08 08:00:27 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>parameter_types</structfield> <type>regtype[]</type>
</para>
<para>
2006-01-16 19:15:31 +01:00
The expected parameter types for the prepared statement in the
form of an array of <type>regtype</type>. The OID corresponding
to an element of this array can be obtained by casting the
2010-08-17 06:37:21 +02:00
<type>regtype</type> value to <type>oid</type>.
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-08 08:00:27 +01:00
</row>
2020-05-14 05:03:39 +02:00
2006-01-08 08:00:27 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>from_sql</structfield> <type>bool</type>
</para>
<para>
2006-01-08 08:00:27 +01:00
<literal>true</literal> if the prepared statement was created
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
via the <command>PREPARE</command> SQL command;
2006-01-08 08:00:27 +01:00
<literal>false</literal> if the statement was prepared via the
2006-01-16 19:15:31 +01:00
frontend/backend protocol
2020-05-14 05:03:39 +02:00
</para></entry>
2006-01-08 08:00:27 +01:00
</row>
2020-07-20 04:55:50 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>generic_plans</structfield> <type>int8</type>
</para>
<para>
Number of times generic plan was chosen
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>custom_plans</structfield> <type>int8</type>
</para>
<para>
Number of times custom plan was chosen
</para></entry>
</row>
2006-01-08 08:00:27 +01:00
</tbody>
</tgroup>
</table>
<para>
The <structname>pg_prepared_statements</structname> view is read only.
</para>
</sect1>
2005-06-18 00:32:51 +02:00
<sect1 id="view-pg-prepared-xacts">
<title><structname>pg_prepared_xacts</structname></title>
<indexterm zone="view-pg-prepared-xacts">
<primary>pg_prepared_xacts</primary>
</indexterm>
<para>
The view <structname>pg_prepared_xacts</structname> displays
information about transactions that are currently prepared for two-phase
2017-11-23 15:39:47 +01:00
commit (see <xref linkend="sql-prepare-transaction"/> for details).
2005-06-18 00:32:51 +02:00
</para>
<para>
<structname>pg_prepared_xacts</structname> contains one row per prepared
transaction. An entry is removed when the transaction is committed or
rolled back.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_prepared_xacts</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2005-06-18 00:32:51 +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-18 00:32:51 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2005-06-18 00:32:51 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>transaction</structfield> <type>xid</type>
</para>
<para>
2005-06-18 00:32:51 +02:00
Numeric transaction identifier of the prepared transaction
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-18 00:32:51 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-06-18 00:32:51 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>gid</structfield> <type>text</type>
</para>
<para>
2005-06-18 00:32:51 +02:00
Global transaction identifier that was assigned to the transaction
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-18 00:32:51 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-06-18 21:33:42 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prepared</structfield> <type>timestamptz</type>
</para>
<para>
2005-06-18 21:33:42 +02:00
Time at which the transaction was prepared for commit
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-18 21:33:42 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-06-18 00:32:51 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>owner</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
2005-06-18 00:32:51 +02:00
Name of the user that executed the transaction
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-18 00:32:51 +02:00
</row>
2020-05-14 05:03:39 +02:00
2005-06-18 00:32:51 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>database</structfield> <type>name</type>
(references <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>datname</structfield>)
</para>
<para>
2005-06-18 00:32:51 +02:00
Name of the database in which the transaction was executed
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-18 00:32:51 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
When the <structname>pg_prepared_xacts</structname> view is accessed, the
internal transaction manager data structures are momentarily locked, and
a copy is made for the view to display. This ensures that the
view produces a consistent set of results, while not blocking
normal operations longer than necessary. Nonetheless
there could be some impact on database performance if this view is
2006-11-12 07:25:37 +01:00
frequently accessed.
2005-06-18 00:32:51 +02:00
</para>
</sect1>
2017-01-19 18:00:00 +01:00
<sect1 id="view-pg-publication-tables">
<title><structname>pg_publication_tables</structname></title>
<indexterm zone="view-pg-publication-tables">
<primary>pg_publication_tables</primary>
</indexterm>
<para>
The view <structname>pg_publication_tables</structname> provides
information about the mapping between publications and the tables they
2020-09-03 13:15:53 +02:00
contain. Unlike the underlying catalog
<link linkend="catalog-pg-publication-rel"><structname>pg_publication_rel</structname></link>,
this view expands
2017-01-19 18:00:00 +01:00
publications defined as <literal>FOR ALL TABLES</literal>, so for such
publications there will be a row for each eligible table.
</para>
<table>
<title><structname>pg_publication_tables</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>pubname</structfield> <type>name</type>
(references <link linkend="catalog-pg-publication"><structname>pg_publication</structname></link>.<structfield>pubname</structfield>)
</para>
<para>
Name of 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>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table
</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>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table
</para></entry>
2017-01-19 18:00:00 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2016-05-05 18:33:12 +02:00
<sect1 id="view-pg-replication-origin-status">
<title><structname>pg_replication_origin_status</structname></title>
<indexterm zone="view-pg-replication-origin-status">
<primary>pg_replication_origin_status</primary>
</indexterm>
<para>
The <structname>pg_replication_origin_status</structname> view
contains information about how far replay for a certain origin has
progressed. 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>
<table>
<title><structname>pg_replication_origin_status</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>local_id</structfield> <type>oid</type>
(references <link linkend="catalog-pg-replication-origin"><structname>pg_replication_origin</structname></link>.<structfield>roident</structfield>)
</para>
<para>
internal node identifier
</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>external_id</structfield> <type>text</type>
(references <link linkend="catalog-pg-replication-origin"><structname>pg_replication_origin</structname></link>.<structfield>roname</structfield>)
</para>
<para>
external node identifier
</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>remote_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
The origin node's LSN up to which data has been replicated.
</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>local_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
2016-05-05 18:33:12 +02:00
This node's LSN at which <literal>remote_lsn</literal> has
been replicated. Used to flush commit records before persisting
data to disk when using asynchronous commits.
2020-05-14 05:03:39 +02:00
</para></entry>
2016-05-05 18:33:12 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="view-pg-replication-slots">
<title><structname>pg_replication_slots</structname></title>
<indexterm zone="view-pg-replication-slots">
<primary>pg_replication_slots</primary>
</indexterm>
<para>
The <structname>pg_replication_slots</structname> view provides a listing
of all replication slots that currently exist on the database cluster,
along with their current state.
</para>
<para>
For more on replication slots,
2017-11-23 15:39:47 +01:00
see <xref linkend="streaming-replication-slots"/> and <xref linkend="logicaldecoding"/>.
2016-05-05 18:33:12 +02:00
</para>
<table>
<title><structname>pg_replication_slots</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>slot_name</structfield> <type>name</type>
</para>
<para>
A unique, cluster-wide identifier for the replication slot
</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>plugin</structfield> <type>name</type>
</para>
<para>
The base name of the shared object containing the output plugin this logical slot is using, or null for physical slots.
</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>slot_type</structfield> <type>text</type>
</para>
<para>
The slot type: <literal>physical</literal> or <literal>logical</literal>
</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>datoid</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 this slot is associated with, or
null. Only logical slots have an associated database.
</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>database</structfield> <type>name</type>
(references <link linkend="catalog-pg-database"><structname>pg_database</structname></link>.<structfield>datname</structfield>)
</para>
<para>
The name of the database this slot is associated with, or
null. Only logical slots have an associated database.
</para></entry>
2016-05-05 18:33:12 +02:00
</row>
2017-01-20 16:55:36 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>temporary</structfield> <type>bool</type>
</para>
<para>
True if this is a temporary replication slot. Temporary slots are
not saved to disk and are automatically dropped on error or when
the session has finished.
</para></entry>
2017-01-20 16:55:36 +01:00
</row>
2016-05-05 18:33:12 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>active</structfield> <type>bool</type>
</para>
<para>
True if this slot is currently actively being used
</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>active_pid</structfield> <type>int4</type>
</para>
<para>
The process ID of the session using this slot if the slot
2016-05-05 18:33:12 +02:00
is currently actively being used. <literal>NULL</literal> if
inactive.
2020-05-14 05:03:39 +02:00
</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>xmin</structfield> <type>xid</type>
</para>
<para>
The oldest transaction that this slot needs the database to
retain. <literal>VACUUM</literal> cannot remove tuples deleted
by any later transaction.
</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>catalog_xmin</structfield> <type>xid</type>
</para>
<para>
The oldest transaction affecting the system catalogs that this
slot needs the database to retain. <literal>VACUUM</literal> cannot
remove catalog tuples deleted by any later transaction.
</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>restart_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
The address (<literal>LSN</literal>) of oldest WAL which still
might be required by the consumer of this slot and thus won't be
2020-07-03 05:08:35 +02:00
automatically removed during checkpoints unless this LSN
gets behind more than <xref linkend="guc-max-slot-wal-keep-size"/>
from the current LSN. <literal>NULL</literal>
2020-05-14 05:03:39 +02:00
if the <literal>LSN</literal> of this slot has never been reserved.
</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>confirmed_flush_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
The address (<literal>LSN</literal>) up to which the logical
slot's consumer has confirmed receiving data. Data older than this is
not available anymore. <literal>NULL</literal> for physical slots.
</para></entry>
2016-05-05 18:33:12 +02:00
</row>
2020-04-08 00:35:00 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_status</structfield> <type>text</type>
</para>
<para>
Availability of WAL files claimed by this slot.
Possible values are:
<itemizedlist>
<listitem>
2020-06-24 20:23:39 +02:00
<para><literal>reserved</literal> means that the claimed files
2020-05-14 05:03:39 +02:00
are within <varname>max_wal_size</varname>.</para>
</listitem>
<listitem>
2020-06-24 20:23:39 +02:00
<para><literal>extended</literal> means
2020-05-14 05:03:39 +02:00
that <varname>max_wal_size</varname> is exceeded but the files are
2020-06-24 20:23:39 +02:00
still retained, either by the replication slot or
2020-07-20 06:30:18 +02:00
by <varname>wal_keep_size</varname>.
2020-06-24 20:23:39 +02:00
</para>
2020-05-14 05:03:39 +02:00
</listitem>
<listitem>
2020-06-24 20:23:39 +02:00
<para>
<literal>unreserved</literal> means that the slot no longer
retains the required WAL files and some of them are to be removed at
the next checkpoint. This state can return
to <literal>reserved</literal> or <literal>extended</literal>.
</para>
</listitem>
<listitem>
<para>
<literal>lost</literal> means that some required WAL files have
been removed and this slot is no longer usable.
</para>
2020-05-14 05:03:39 +02:00
</listitem>
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
non-negative. If <structfield>restart_lsn</structfield> is NULL, this
field is null.
</para></entry>
2020-04-08 00:35:00 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
2020-07-07 19:08:00 +02:00
<structfield>safe_wal_size</structfield> <type>int8</type>
2020-05-14 05:03:39 +02:00
</para>
<para>
2020-07-07 19:08:00 +02:00
The number of bytes that can be written to WAL such that this slot
is not in danger of getting in state "lost". It is NULL for lost
slots, as well as if <varname>max_slot_wal_keep_size</varname>
is <literal>-1</literal>.
2020-05-14 05:03:39 +02:00
</para></entry>
2020-04-08 00:35:00 +02:00
</row>
2016-05-05 18:33:12 +02:00
</tbody>
</tgroup>
</table>
</sect1>
2005-06-28 07:09:14 +02:00
<sect1 id="view-pg-roles">
<title><structname>pg_roles</structname></title>
<indexterm zone="view-pg-roles">
<primary>pg_roles</primary>
</indexterm>
<para>
The view <structname>pg_roles</structname> provides access to
information about database roles. This is simply a publicly
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
readable view of
2005-06-28 07:09:14 +02:00
<link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>
that blanks out the password field.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_roles</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">
<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
2006-11-12 07:25:37 +01:00
session authorization identifier
2020-05-14 05:03:39 +02:00
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
2011-07-04 04:12:14 +02: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>
2011-07-04 04:12:14 +02: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>
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
For roles that can log in, this sets maximum number of concurrent
2010-08-17 06:37:21 +02:00
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>
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>rolpassword</structfield> <type>text</type>
</para>
<para>
Not the password (always reads as <literal>********</literal>)
</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>rolvaliduntil</structfield> <type>timestamptz</type>
</para>
<para>
Password expiry time (only used for password authentication);
null if no expiration
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
2011-07-04 04:12:14 +02:00
2016-06-20 10:29:20 +02: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>
2016-06-20 10:29:20 +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>
2016-06-20 10:29:20 +02:00
</row>
2011-07-04 04:12:14 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rolconfig</structfield> <type>text[]</type>
</para>
<para>
Role-specific defaults for run-time configuration variables
</para></entry>
2011-07-04 04:12:14 +02:00
</row>
2005-06-28 07:09:14 +02:00
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>oid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of role
</para></entry>
2005-07-26 18:38:29 +02:00
</row>
2005-06-28 07:09:14 +02:00
</tbody>
</tgroup>
</table>
</sect1>
2003-10-18 00:38:20 +02:00
<sect1 id="view-pg-rules">
<title><structname>pg_rules</structname></title>
<indexterm zone="view-pg-rules">
<primary>pg_rules</primary>
</indexterm>
<para>
The view <structname>pg_rules</structname> provides access to
useful information about query rewrite rules.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_rules</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table the rule is for
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +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>
(references <link linkend="catalog-pg-rewrite"><structname>pg_rewrite</structname></link>.<structfield>rulename</structfield>)
</para>
<para>
Name of rule
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>definition</structfield> <type>text</type>
</para>
<para>
Rule definition (a reconstructed creation command)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
2017-10-09 03:44:17 +02:00
The <structname>pg_rules</structname> view excludes the <literal>ON SELECT</literal> rules
2013-03-06 22:35:59 +01:00
of views and materialized views; those can be seen in
2020-09-03 13:15:53 +02:00
<link linkend="view-pg-views"><structname>pg_views</structname></link> and <link linkend="view-pg-matviews"><structname>pg_matviews</structname></link>.
2003-10-18 00:38:20 +02:00
</para>
</sect1>
2010-09-28 02:55:27 +02:00
<sect1 id="view-pg-seclabels">
<title><structname>pg_seclabels</structname></title>
<indexterm zone="view-pg-seclabels">
<primary>pg_seclabels</primary>
</indexterm>
<para>
The view <structname>pg_seclabels</structname> provides information about
security labels. It as an easier-to-query version of the
2017-10-09 03:44:17 +02:00
<link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link> catalog.
2010-09-28 02:55:27 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_seclabels</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>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +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>
2010-09-28 02:55:27 +02:00
</row>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +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>
2010-09-28 02:55:27 +02:00
</row>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +02: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>
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>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objtype</structfield> <type>text</type>
</para>
<para>
The type of object to which this label applies, as text.
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objnamespace</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2010-09-28 02:55:27 +02:00
The OID of the namespace for this object, if applicable;
otherwise NULL.
2020-05-14 05:03:39 +02:00
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>objname</structfield> <type>text</type>
</para>
<para>
2010-09-28 02:55:27 +02:00
The name of the object to which this label applies, as text.
2020-05-14 05:03:39 +02:00
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +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>
(references <link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link>.<structfield>provider</structfield>)
</para>
<para>
The label provider associated with this label.
</para></entry>
2010-09-28 02:55:27 +02:00
</row>
2020-05-14 05:03:39 +02:00
2010-09-28 02:55:27 +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>
(references <link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link>.<structfield>label</structfield>)
</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-11-18 18:00:00 +01:00
<sect1 id="view-pg-sequences">
<title><structname>pg_sequences</structname></title>
<indexterm zone="view-pg-sequences">
<primary>pg_sequences</primary>
</indexterm>
<para>
The view <structname>pg_sequences</structname> provides access to
useful information about each sequence in the database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_sequences</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2016-11-18 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-11-18 18:00:00 +01:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sequencename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sequenceowner</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
Name of sequence's owner
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
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>data_type</structfield> <type>regtype</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Data type of the sequence
</para></entry>
2017-02-10 21:12:32 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>start_value</structfield> <type>int8</type>
</para>
<para>
Start value of the sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>min_value</structfield> <type>int8</type>
</para>
<para>
Minimum value of the sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>max_value</structfield> <type>int8</type>
</para>
<para>
Maximum value of the sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>increment_by</structfield> <type>int8</type>
</para>
<para>
Increment value of the sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cycle</structfield> <type>bool</type>
</para>
<para>
Whether the sequence cycles
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cache_size</structfield> <type>int8</type>
</para>
<para>
Cache size of the sequence
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
2020-05-14 05:03:39 +02:00
2016-11-18 18:00:00 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_value</structfield> <type>int8</type>
</para>
<para>
The last sequence value written to disk. If caching is used,
2016-11-18 18:00:00 +01:00
this value can be greater than the last value handed out from the
2017-02-06 21:17:27 +01:00
sequence. Null if the sequence has not been read from yet. Also, if
the current user does not have <literal>USAGE</literal>
or <literal>SELECT</literal> privilege on the sequence, the value is
2020-05-14 05:03:39 +02:00
null.
</para></entry>
2016-11-18 18:00:00 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2003-10-18 00:38:20 +02:00
<sect1 id="view-pg-settings">
<title><structname>pg_settings</structname></title>
<indexterm zone="view-pg-settings">
<primary>pg_settings</primary>
</indexterm>
<para>
The view <structname>pg_settings</structname> provides access to
run-time parameters of the server. It is essentially an alternative
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
interface to the <link linkend="sql-show"><command>SHOW</command></link>
and <link linkend="sql-set"><command>SET</command></link> commands.
2003-10-18 00:38:20 +02:00
It also provides access to some facts about each parameter that 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
not directly available from <link linkend="sql-show"><command>SHOW</command></link>, such as minimum and
2003-10-18 00:38:20 +02:00
maximum values.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_settings</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
Run-time configuration parameter name
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>setting</structfield> <type>text</type>
</para>
<para>
Current value of the parameter
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2006-07-27 10:30:41 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>unit</structfield> <type>text</type>
</para>
<para>
Implicit unit of the parameter
</para></entry>
2006-07-27 10:30:41 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-12-07 00:10:23 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>category</structfield> <type>text</type>
</para>
<para>
Logical group of the parameter
</para></entry>
2003-12-07 00:10:23 +01:00
</row>
2020-05-14 05:03:39 +02:00
2003-12-07 00:10:23 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>short_desc</structfield> <type>text</type>
</para>
<para>
A brief description of the parameter
</para></entry>
2003-12-07 00:10:23 +01:00
</row>
2020-05-14 05:03:39 +02:00
2003-12-07 00:10:23 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>extra_desc</structfield> <type>text</type>
</para>
<para>
Additional, more detailed, description of the parameter
</para></entry>
2003-12-07 00:10:23 +01:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>context</structfield> <type>text</type>
</para>
<para>
Context required to set the parameter's value (see below)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>vartype</structfield> <type>text</type>
</para>
<para>
Parameter type (<literal>bool</literal>, <literal>enum</literal>,
2017-10-09 03:44:17 +02:00
<literal>integer</literal>, <literal>real</literal>, or <literal>string</literal>)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>source</structfield> <type>text</type>
</para>
<para>
Source of the current parameter value
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>min_val</structfield> <type>text</type>
</para>
<para>
Minimum allowed value of the parameter (null for non-numeric
values)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>max_val</structfield> <type>text</type>
</para>
<para>
Maximum allowed value of the parameter (null for non-numeric
values)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2008-03-10 13:55:13 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>enumvals</structfield> <type>text[]</type>
</para>
<para>
Allowed values of an enum parameter (null for non-enum
values)
</para></entry>
2008-03-10 13:55:13 +01:00
</row>
2020-05-14 05:03:39 +02:00
2008-10-06 15:05:40 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>boot_val</structfield> <type>text</type>
</para>
<para>
Parameter value assumed at server startup if the parameter is
not otherwise set
</para></entry>
2008-10-06 15:05:40 +02:00
</row>
2020-05-14 05:03:39 +02:00
2008-10-06 15:05:40 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reset_val</structfield> <type>text</type>
</para>
<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
Value that <link linkend="sql-reset"><command>RESET</command></link> would reset the parameter to
2020-05-14 05:03:39 +02:00
in the current session
</para></entry>
2008-10-06 15:05:40 +02:00
</row>
2020-05-14 05:03:39 +02:00
2008-09-10 20:09:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sourcefile</structfield> <type>text</type>
</para>
<para>
Configuration file the current value was set in (null for
values set from sources other than configuration files, or when
examined by a user who is neither a superuser or a member of
<literal>pg_read_all_settings</literal>); helpful when using
<literal>include</literal> directives in configuration files
</para></entry>
2008-09-10 20:09:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2008-09-10 20:09:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sourceline</structfield> <type>int4</type>
</para>
<para>
Line number within the configuration file the current value was
set at (null for values set from sources other than configuration files,
or when examined by a user who is neither a superuser or a member of
<literal>pg_read_all_settings</literal>).
</para></entry>
2008-09-10 20:09:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2015-05-15 02:08:51 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pending_restart</structfield> <type>bool</type>
</para>
<para>
<literal>true</literal> if the value has been changed in the
configuration file but needs a restart; or <literal>false</literal>
otherwise.
</para></entry>
2015-05-15 02:08:51 +02:00
</row>
2003-10-18 00:38:20 +02: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
2011-03-17 05:26:03 +01:00
<para>
There are several possible values of <structfield>context</structfield>.
In order of decreasing difficulty of changing the setting, they are:
</para>
<variablelist>
<varlistentry>
2015-03-15 17:45:35 +01:00
<!-- PGC_INTERNAL -->
2011-03-17 05:26:03 +01:00
<term><literal>internal</literal></term>
<listitem>
<para>
These settings cannot be changed directly; they reflect internally
determined values. Some of them may be adjustable by rebuilding the
server with different configuration options, or by changing options
2020-09-03 13:15:53 +02:00
supplied to <application>initdb</application>.
2011-03-17 05:26:03 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
2015-03-15 17:45:35 +01:00
<!-- PGC_POSTMASTER -->
2011-03-17 05:26:03 +01:00
<term><literal>postmaster</literal></term>
<listitem>
<para>
These settings can only be applied when the server starts, so any change
requires restarting the server. Values for these settings are typically
stored in the <filename>postgresql.conf</filename> file, or passed on
the command line when starting the server. Of course, settings with any
of the lower <structfield>context</structfield> types can also be
set at server start time.
</para>
</listitem>
</varlistentry>
<varlistentry>
2015-03-15 17:45:35 +01:00
<!-- PGC_SIGHUP -->
2011-03-17 05:26:03 +01:00
<term><literal>sighup</literal></term>
<listitem>
<para>
Changes to these settings can be made in
<filename>postgresql.conf</filename> without restarting the server.
Send a <systemitem>SIGHUP</systemitem> signal to the postmaster to
cause it to re-read <filename>postgresql.conf</filename> and apply
the changes. The postmaster will also forward the
<systemitem>SIGHUP</systemitem> signal to its child processes so that
they all pick up the new value.
</para>
</listitem>
</varlistentry>
<varlistentry>
2015-03-15 17:45:35 +01:00
<!-- PGC_SU_BACKEND -->
<term><literal>superuser-backend</literal></term>
<listitem>
<para>
Changes to these settings can be made in
<filename>postgresql.conf</filename> without restarting the server.
They can also be set for a particular session in the connection request
2017-10-09 03:44:17 +02:00
packet (for example, via <application>libpq</application>'s <literal>PGOPTIONS</literal>
2015-03-15 17:45:35 +01:00
environment variable), but only if the connecting user is a superuser.
However, these settings never change in a session after it is started.
If you change them in <filename>postgresql.conf</filename>, send a
<systemitem>SIGHUP</systemitem> signal to the postmaster to cause it to
re-read <filename>postgresql.conf</filename>. The new values will only
affect subsequently-launched sessions.
</para>
</listitem>
</varlistentry>
<varlistentry>
<!-- PGC_BACKEND -->
2011-03-17 05:26:03 +01:00
<term><literal>backend</literal></term>
<listitem>
<para>
Changes to these settings can be made in
2015-03-15 17:45:35 +01:00
<filename>postgresql.conf</filename> without restarting the server.
They can also be set for a particular session in the connection request
2017-10-09 03:44:17 +02:00
packet (for example, via <application>libpq</application>'s <literal>PGOPTIONS</literal>
2015-09-22 04:57:29 +02:00
environment variable); any user can make such a change for their session.
2015-03-15 17:45:35 +01:00
However, these settings never change in a session after it is started.
If you change them in <filename>postgresql.conf</filename>, send a
2011-03-17 05:26:03 +01:00
<systemitem>SIGHUP</systemitem> signal to the postmaster to cause it to
re-read <filename>postgresql.conf</filename>. The new values will only
affect subsequently-launched sessions.
</para>
</listitem>
</varlistentry>
<varlistentry>
2015-03-15 17:45:35 +01:00
<!-- PGC_SUSET -->
2011-03-17 05:26:03 +01:00
<term><literal>superuser</literal></term>
<listitem>
<para>
These settings can be set from <filename>postgresql.conf</filename>,
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
or within a session via the <command>SET</command> command; but only superusers
2017-10-09 03:44:17 +02:00
can change them via <command>SET</command>. Changes in
2011-03-17 05:26:03 +01:00
<filename>postgresql.conf</filename> will affect existing sessions
2017-10-09 03:44:17 +02:00
only if no session-local value has been established with <command>SET</command>.
2011-03-17 05:26:03 +01:00
</para>
</listitem>
</varlistentry>
<varlistentry>
2015-03-15 17:45:35 +01:00
<!-- PGC_USERSET -->
2011-03-17 05:26:03 +01:00
<term><literal>user</literal></term>
<listitem>
<para>
These settings can be set from <filename>postgresql.conf</filename>,
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
or within a session via the <command>SET</command> command. Any user is
2015-09-22 04:57:29 +02:00
allowed to change their session-local value. Changes in
2011-03-17 05:26:03 +01:00
<filename>postgresql.conf</filename> will affect existing sessions
2017-10-09 03:44:17 +02:00
only if no session-local value has been established with <command>SET</command>.
2011-03-17 05:26:03 +01:00
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
2017-11-23 15:39:47 +01:00
See <xref linkend="config-setting"/> for more information about the various
2011-03-17 05:26:03 +01:00
ways to change these parameters.
</para>
2003-10-18 00:38:20 +02:00
<para>
The <structname>pg_settings</structname> view cannot be inserted into or
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
deleted from, but it can be updated. An <command>UPDATE</command> applied
2003-10-18 00:38:20 +02:00
to a row of <structname>pg_settings</structname> is equivalent to executing
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 <command>SET</command> command on that named
2003-10-18 00:38:20 +02:00
parameter. The change only affects the value used by the current
session. If an <command>UPDATE</command> is issued within a transaction
that is later aborted, the effects of the <command>UPDATE</command> command
disappear when the transaction is rolled back. Once the surrounding
transaction is committed, the effects will persist until the end of the
session, unless overridden by another <command>UPDATE</command> or
<command>SET</command>.
</para>
</sect1>
2005-06-28 07:09:14 +02:00
<sect1 id="view-pg-shadow">
<title><structname>pg_shadow</structname></title>
<indexterm zone="view-pg-shadow">
<primary>pg_shadow</primary>
</indexterm>
<para>
The view <structname>pg_shadow</structname> exists for backwards
compatibility: it emulates a catalog that existed in
<productname>PostgreSQL</productname> before version 8.1.
It shows properties of all roles that are marked as
2017-10-09 03:44:17 +02:00
<structfield>rolcanlogin</structfield> in
2010-09-13 19:02:34 +02:00
<link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.
2005-06-28 07:09:14 +02:00
</para>
<para>
The name stems from the fact that this table
should not be readable by the public since it contains passwords.
<link linkend="view-pg-user"><structname>pg_user</structname></link>
is a publicly readable view on
<structname>pg_shadow</structname> that blanks out the password field.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_shadow</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">
<structfield>usename</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
User 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>usesysid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of this user
</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>usecreatedb</structfield> <type>bool</type>
</para>
<para>
User 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>usesuper</structfield> <type>bool</type>
</para>
<para>
User is a superuser
</para></entry>
2005-06-28 07:09:14 +02: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>userepl</structfield> <type>bool</type>
</para>
<para>
2012-04-06 22:54:27 +02:00
User can initiate streaming replication and put the system in and
out of backup mode.
2020-05-14 05:03:39 +02:00
</para></entry>
2012-04-06 22:54:27 +02: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>usebypassrls</structfield> <type>bool</type>
</para>
<para>
2015-10-04 02:19:57 +02:00
User 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-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>passwd</structfield> <type>text</type>
</para>
<para>
Password (possibly encrypted); null if none. See
<link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>
for details of how encrypted passwords are stored.
</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>valuntil</structfield> <type>timestamptz</type>
</para>
<para>
Password expiry time (only used for password authentication)
</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>useconfig</structfield> <type>text[]</type>
</para>
<para>
Session defaults for run-time configuration variables
</para></entry>
2005-06-28 07:09:14 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2020-01-09 16:59:07 +01:00
<sect1 id="view-pg-shmem-allocations">
<title><structname>pg_shmem_allocations</structname></title>
<indexterm zone="view-pg-shmem-allocations">
<primary>pg_shmem_allocations</primary>
</indexterm>
<para>
The <structname>pg_shmem_allocations</structname> view shows allocations
made from the server's main shared memory segment. This includes both
memory allocated by <productname>postgres</productname> itself and memory
allocated by extensions using the mechanisms detailed in
<xref linkend="xfunc-shared-addin" />.
</para>
<para>
Note that this view does not include memory allocated using the dynamic
shared memory infrastructure.
</para>
<table>
<title><structname>pg_shmem_allocations</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2020-01-09 16:59:07 +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>
2020-01-09 16:59:07 +01:00
</row>
</thead>
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
The name of the shared memory allocation. NULL for unused memory
and <literal><anonymous></literal> for anonymous
allocations.
</para></entry>
2020-01-09 16:59:07 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>off</structfield> <type>int8</type>
</para>
<para>
The offset at which the allocation starts. NULL for anonymous
allocations and unused memory.
</para></entry>
2020-01-09 16:59:07 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>size</structfield> <type>int8</type>
</para>
<para>
Size of the allocation
</para></entry>
2020-01-09 16:59:07 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>allocated_size</structfield> <type>int8</type>
</para>
<para>
Size of the allocation including padding. For anonymous
allocations, no information about padding is available, so the
<literal>size</literal> and <literal>allocated_size</literal> columns
will always be equal. Padding is not meaningful for free memory, so
the columns will be equal in that case also.
</para></entry>
2020-01-09 16:59:07 +01:00
</row>
</tbody>
</tgroup>
</table>
<para>
Anonymous allocations are allocations that have been made
with <literal>ShmemAlloc()</literal> directly, rather than via
<literal>ShmemInitStruct()</literal> or
<literal>ShmemInitHash()</literal>.
</para>
<para>
By default, the <structname>pg_shmem_allocations</structname> view can be
read only by superusers.
</para>
</sect1>
2003-10-18 00:38:20 +02:00
<sect1 id="view-pg-stats">
<title><structname>pg_stats</structname></title>
<indexterm zone="view-pg-stats">
<primary>pg_stats</primary>
</indexterm>
<para>
The view <structname>pg_stats</structname> provides access to
the information stored in the <link
linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link>
catalog. This view allows access only to rows of
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link> that correspond to tables the
2003-10-18 00:38:20 +02:00
user has permission to read, and therefore it is safe to allow public
read access to this view.
</para>
<para>
<structname>pg_stats</structname> is also designed to present the
information in a more readable format than the underlying catalog
2004-11-15 07:32:15 +01:00
— at the cost that its schema must be extended whenever new slot types
2020-09-03 13:15:53 +02:00
are defined for <link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link>.
2003-10-18 00:38:20 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_stats</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table
</para></entry>
2003-10-18 00:38:20 +02: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>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attname</structfield>)
</para>
<para>
Name of the column described by this row
</para></entry>
2003-10-18 00:38:20 +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>inherited</structfield> <type>bool</type>
</para>
<para>
If true, this row includes inheritance child columns, not just the
values in the specified table
</para></entry>
2009-12-29 21:11:45 +01:00
</row>
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>null_frac</structfield> <type>float4</type>
</para>
<para>
Fraction of column entries that are null
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>avg_width</structfield> <type>int4</type>
</para>
<para>
Average width in bytes of column's entries
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_distinct</structfield> <type>float4</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
If greater than zero, the estimated number of distinct values in the
column. If less than zero, the negative of the number of distinct
values divided by the number of rows. (The negated form is used when
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
<command>ANALYZE</command> believes that the number of distinct values is
2006-11-12 07:25:37 +01:00
likely to increase as the table grows; the positive form is used when
the column seems to have a fixed number of possible values.) For
example, -1 indicates a unique column in which the number of distinct
2010-08-17 06:37:21 +02:00
values is the same as the number of rows.
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_vals</structfield> <type>anyarray</type>
</para>
<para>
2010-08-17 06:37:21 +02:00
A list of the most common values in the column. (Null if
2006-11-12 07:25:37 +01:00
no values seem to be more common than any others.)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_freqs</structfield> <type>float4[]</type>
</para>
<para>
2012-03-04 02:20:19 +01:00
A list of the frequencies of the most common values,
2006-11-12 07:25:37 +01:00
i.e., number of occurrences of each divided by total number of rows.
2010-08-17 06:37:21 +02:00
(Null when <structfield>most_common_vals</structfield> is.)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>histogram_bounds</structfield> <type>anyarray</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
A list of values that divide the column's values into groups of
approximately equal population. The values in
2017-10-09 03:44:17 +02:00
<structfield>most_common_vals</structfield>, if present, are omitted from this
2010-08-17 06:37:21 +02:00
histogram calculation. (This column is null if the column data type
2017-10-09 03:44:17 +02:00
does not have a <literal><</literal> operator or if the
<structfield>most_common_vals</structfield> list accounts for the entire
2006-11-12 07:25:37 +01:00
population.)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>correlation</structfield> <type>float4</type>
</para>
<para>
2006-11-12 07:25:37 +01:00
Statistical correlation between physical row ordering and
logical ordering of the column values. This ranges from -1 to +1.
When the value is near -1 or +1, an index scan on the column will
be estimated to be cheaper than when it is near zero, due to reduction
2010-08-17 06:37:21 +02:00
of random access to the disk. (This column is null if the column data
2017-10-09 03:44:17 +02:00
type does not have a <literal><</literal> operator.)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2012-03-04 02:20:19 +01:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_elems</structfield> <type>anyarray</type>
</para>
<para>
2012-03-04 02:20:19 +01:00
A list of non-null element values most often appearing within values of
the column. (Null for scalar types.)
2020-05-14 05:03:39 +02:00
</para></entry>
2012-03-04 02:20:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_elem_freqs</structfield> <type>float4[]</type>
</para>
<para>
2012-03-04 02:20:19 +01:00
A list of the frequencies of the most common element values, i.e., the
fraction of rows containing at least one instance of the given value.
Two or three additional values follow the per-element frequencies;
these are the minimum and maximum of the preceding per-element
frequencies, and optionally the frequency of null elements.
(Null when <structfield>most_common_elems</structfield> is.)
2020-05-14 05:03:39 +02:00
</para></entry>
2012-03-04 02:20:19 +01:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>elem_count_histogram</structfield> <type>float4[]</type>
</para>
<para>
2012-03-04 02:20:19 +01:00
A histogram of the counts of distinct non-null element values within the
values of the column, followed by the average number of distinct
non-null elements. (Null for scalar types.)
2020-05-14 05:03:39 +02:00
</para></entry>
2012-03-04 02:20:19 +01:00
</row>
2003-10-18 00:38:20 +02:00
</tbody>
</tgroup>
</table>
<para>
2012-03-04 02:20:19 +01:00
The maximum number of entries in the array fields can be controlled on a
2020-09-03 13:15:53 +02:00
column-by-column basis using the <link linkend="sql-altertable"><command>ALTER
TABLE SET STATISTICS</command></link>
2019-06-13 17:25:04 +02:00
command, or globally by setting the
<xref linkend="guc-default-statistics-target"/> run-time parameter.
</para>
</sect1>
<sect1 id="view-pg-stats-ext">
<title><structname>pg_stats_ext</structname></title>
<indexterm zone="view-pg-stats-ext">
<primary>pg_stats_ext</primary>
</indexterm>
<para>
The view <structname>pg_stats_ext</structname> provides access to
the information stored in the <link
linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>
and <link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link>
catalogs. This view allows access only to rows of
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link> and <link linkend="catalog-pg-statistic-ext-data"><structname>pg_statistic_ext_data</structname></link>
2019-06-13 17:25:04 +02:00
that correspond to tables the user has permission to read, and therefore
it is safe to allow public read access to this view.
</para>
<para>
<structname>pg_stats_ext</structname> is also designed to present the
2019-08-20 05:36:31 +02:00
information in a more readable format than the underlying catalogs
2019-06-13 17:25:04 +02:00
— at the cost that its schema must be extended whenever new types
2020-09-03 13:15:53 +02:00
of extended statistics are added to <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.
2019-06-13 17:25:04 +02:00
</para>
<table>
<title><structname>pg_stats_ext</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2019-06-13 17:25:04 +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>
2019-06-13 17:25:04 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2019-06-13 17:25:04 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>statistics_schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing extended statistic
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>statistics_name</structfield> <type>name</type>
(references <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.<structfield>stxname</structfield>)
</para>
<para>
Name of extended statistics
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>statistics_owner</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
Owner of the extended statistics
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attnames</structfield> <type>name[]</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attname</structfield>)
</para>
<para>
Names of the columns the extended statistics is defined on
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>kinds</structfield> <type>char[]</type>
</para>
<para>
Types of extended statistics enabled for this record
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_distinct</structfield> <type>pg_ndistinct</type>
</para>
<para>
N-distinct counts for combinations of column values. If greater
2019-08-20 05:36:31 +02:00
than zero, the estimated number of distinct values in the combination.
If less than zero, the negative of the number of distinct values divided
2019-06-13 17:25:04 +02:00
by the number of rows.
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 negated form is used when <command>ANALYZE</command> believes that
2019-06-13 17:25:04 +02:00
the number of distinct values is likely to increase as the table grows;
the positive form is used when the column seems to have a fixed number
of possible values.) For example, -1 indicates a unique combination of
columns in which the number of distinct combinations is the same as the
number of rows.
2020-05-14 05:03:39 +02:00
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dependencies</structfield> <type>pg_dependencies</type>
</para>
<para>
Functional dependency statistics
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_vals</structfield> <type>text[]</type>
</para>
<para>
2019-08-20 05:36:31 +02:00
A list of the most common combinations of values in the columns.
(Null if no combinations seem to be more common than any others.)
2020-05-14 05:03:39 +02:00
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_val_nulls</structfield> <type>bool[]</type>
</para>
<para>
2019-06-13 17:25:04 +02:00
A list of NULL flags for the most common combinations of values.
(Null when <structfield>most_common_vals</structfield> is.)
2020-05-14 05:03:39 +02:00
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_freqs</structfield> <type>float8[]</type>
</para>
<para>
2019-06-13 17:25:04 +02:00
A list of the frequencies of the most common combinations,
i.e., number of occurrences of each divided by total number of rows.
(Null when <structfield>most_common_vals</structfield> is.)
2020-05-14 05:03:39 +02:00
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>most_common_base_freqs</structfield> <type>float8[]</type>
</para>
<para>
2019-06-13 17:25:04 +02:00
A list of the base frequencies of the most common combinations,
i.e., product of per-value frequencies.
(Null when <structfield>most_common_vals</structfield> is.)
2020-05-14 05:03:39 +02:00
</para></entry>
2019-06-13 17:25:04 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
The maximum number of entries in the array fields can be controlled on a
2020-09-03 13:15:53 +02:00
column-by-column basis using the <link linkend="sql-altertable"><command>ALTER
TABLE SET STATISTICS</command></link> command, or globally by setting the
2017-11-23 15:39:47 +01:00
<xref linkend="guc-default-statistics-target"/> run-time parameter.
2003-10-18 00:38:20 +02:00
</para>
</sect1>
<sect1 id="view-pg-tables">
<title><structname>pg_tables</structname></title>
<indexterm zone="view-pg-tables">
<primary>pg_tables</primary>
</indexterm>
<para>
The view <structname>pg_tables</structname> provides access to
useful information about each table in the database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_tables</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing table
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablename</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of table
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tableowner</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
Name of table's owner
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2004-10-11 19:24:41 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablespace</structfield> <type>name</type>
(references <link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.<structfield>spcname</structfield>)
</para>
<para>
Name of tablespace containing table (null if default for database)
</para></entry>
2004-10-11 19:24:41 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>hasindexes</structfield> <type>bool</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relhasindex</structfield>)
</para>
<para>
True if table has (or recently had) any indexes
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>hasrules</structfield> <type>bool</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relhasrules</structfield>)
</para>
<para>
True if table has (or once had) rules
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>hastriggers</structfield> <type>bool</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relhastriggers</structfield>)
</para>
<para>
True if table has (or once had) triggers
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
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>rowsecurity</structfield> <type>bool</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relrowsecurity</structfield>)
</para>
<para>
True if row security is enabled on the table
</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>
2003-10-18 00:38:20 +02:00
</tbody>
</tgroup>
</table>
</sect1>
2006-09-16 22:14:34 +02:00
<sect1 id="view-pg-timezone-abbrevs">
<title><structname>pg_timezone_abbrevs</structname></title>
2006-07-25 05:51:23 +02:00
2006-09-16 22:14:34 +02:00
<indexterm zone="view-pg-timezone-abbrevs">
<primary>pg_timezone_abbrevs</primary>
2006-07-25 05:51:23 +02:00
</indexterm>
<para>
2006-09-16 22:14:34 +02:00
The view <structname>pg_timezone_abbrevs</structname> provides a list
2006-07-25 05:51:23 +02:00
of time zone abbreviations that are currently recognized by the datetime
input routines. The contents of this view change when the
2017-11-23 15:39:47 +01:00
<xref linkend="guc-timezone-abbreviations"/> run-time parameter is modified.
2006-07-25 05:51:23 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_timezone_abbrevs</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2006-09-16 22:14:34 +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>
2006-09-16 22:14:34 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2006-09-16 22:14:34 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>abbrev</structfield> <type>text</type>
</para>
<para>
Time zone abbreviation
</para></entry>
2006-09-16 22:14:34 +02:00
</row>
2020-05-14 05:03:39 +02:00
2006-09-16 22:14:34 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>utc_offset</structfield> <type>interval</type>
</para>
<para>
Offset from UTC (positive means east of Greenwich)
</para></entry>
2006-09-16 22:14:34 +02:00
</row>
2020-05-14 05:03:39 +02:00
2006-09-16 22:14:34 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>is_dst</structfield> <type>bool</type>
</para>
<para>
True if this is a daylight-savings abbreviation
</para></entry>
2006-09-16 22:14:34 +02:00
</row>
</tbody>
</tgroup>
</table>
Don't require dynamic timezone abbreviations to match underlying time zone.
Previously, we threw an error if a dynamic timezone abbreviation did not
match any abbreviation recorded in the referenced IANA time zone entry.
That seemed like a good consistency check at the time, but it turns out
that a number of the abbreviations in the IANA database are things that
Olson and crew made up out of whole cloth. Their current policy is to
remove such names in favor of using simple numeric offsets. Perhaps
unsurprisingly, a lot of these made-up abbreviations have varied in meaning
over time, which meant that our commit b2cbced9e and later changes made
them into dynamic abbreviations. So with newer IANA database versions
that don't mention these abbreviations at all, we fail, as reported in bug
#14307 from Neil Anderson. It's worse than just a few unused-in-the-wild
abbreviations not working, because the pg_timezone_abbrevs view stops
working altogether (since its underlying function tries to compute the
whole view result in one call).
We considered deleting these abbreviations from our abbreviations list, but
the problem with that is that we can't stay ahead of possible future IANA
changes. Instead, let's leave the abbreviations list alone, and treat any
"orphaned" dynamic abbreviation as just meaning the referenced time zone.
It will behave a bit differently than it used to, in that you can't any
longer override the zone's standard vs. daylight rule by using the "wrong"
abbreviation of a pair, but that's better than failing entirely. (Also,
this solution can be interpreted as adding a small new feature, which is
that any abbreviation a user wants can be defined as referencing a time
zone name.)
Back-patch to all supported branches, since this problem affects all
of them when using tzdata 2016f or newer.
Report: <20160902031551.15674.67337@wrigleys.postgresql.org>
Discussion: <6189.1472820913@sss.pgh.pa.us>
2016-09-02 23:29:31 +02:00
<para>
While most timezone abbreviations represent fixed offsets from UTC,
there are some that have historically varied in value
2017-11-23 15:39:47 +01:00
(see <xref linkend="datetime-config-files"/> for more information).
Don't require dynamic timezone abbreviations to match underlying time zone.
Previously, we threw an error if a dynamic timezone abbreviation did not
match any abbreviation recorded in the referenced IANA time zone entry.
That seemed like a good consistency check at the time, but it turns out
that a number of the abbreviations in the IANA database are things that
Olson and crew made up out of whole cloth. Their current policy is to
remove such names in favor of using simple numeric offsets. Perhaps
unsurprisingly, a lot of these made-up abbreviations have varied in meaning
over time, which meant that our commit b2cbced9e and later changes made
them into dynamic abbreviations. So with newer IANA database versions
that don't mention these abbreviations at all, we fail, as reported in bug
#14307 from Neil Anderson. It's worse than just a few unused-in-the-wild
abbreviations not working, because the pg_timezone_abbrevs view stops
working altogether (since its underlying function tries to compute the
whole view result in one call).
We considered deleting these abbreviations from our abbreviations list, but
the problem with that is that we can't stay ahead of possible future IANA
changes. Instead, let's leave the abbreviations list alone, and treat any
"orphaned" dynamic abbreviation as just meaning the referenced time zone.
It will behave a bit differently than it used to, in that you can't any
longer override the zone's standard vs. daylight rule by using the "wrong"
abbreviation of a pair, but that's better than failing entirely. (Also,
this solution can be interpreted as adding a small new feature, which is
that any abbreviation a user wants can be defined as referencing a time
zone name.)
Back-patch to all supported branches, since this problem affects all
of them when using tzdata 2016f or newer.
Report: <20160902031551.15674.67337@wrigleys.postgresql.org>
Discussion: <6189.1472820913@sss.pgh.pa.us>
2016-09-02 23:29:31 +02:00
In such cases this view presents their current meaning.
</para>
2006-09-16 22:14:34 +02:00
</sect1>
<sect1 id="view-pg-timezone-names">
<title><structname>pg_timezone_names</structname></title>
<indexterm zone="view-pg-timezone-names">
<primary>pg_timezone_names</primary>
</indexterm>
<para>
The view <structname>pg_timezone_names</structname> provides a list
2017-10-09 03:44:17 +02:00
of time zone names that are recognized by <command>SET TIMEZONE</command>,
2006-09-16 22:14:34 +02:00
along with their associated abbreviations, UTC offsets,
2011-09-05 21:37:58 +02:00
and daylight-savings status. (Technically,
2016-06-28 19:49:37 +02:00
<productname>PostgreSQL</productname> does not use UTC because leap
seconds are not handled.)
2006-09-16 22:14:34 +02:00
Unlike the abbreviations shown in <link
linkend="view-pg-timezone-abbrevs"><structname>pg_timezone_abbrevs</structname></link>, many of these names imply a set of daylight-savings transition
date rules. Therefore, the associated information changes across local DST
boundaries. The displayed information is computed based on the current
2017-10-09 03:44:17 +02:00
value of <function>CURRENT_TIMESTAMP</function>.
2006-09-16 22:14:34 +02:00
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_timezone_names</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2006-07-25 05:51:23 +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>
2006-07-25 05:51:23 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2006-07-25 05:51:23 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
Time zone name
</para></entry>
2006-09-16 22:14:34 +02:00
</row>
2020-05-14 05:03:39 +02:00
2006-09-16 22:14:34 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>abbrev</structfield> <type>text</type>
</para>
<para>
Time zone abbreviation
</para></entry>
2006-07-25 05:51:23 +02:00
</row>
2020-05-14 05:03:39 +02:00
2006-07-25 05:51:23 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>utc_offset</structfield> <type>interval</type>
</para>
<para>
Offset from UTC (positive means east of Greenwich)
</para></entry>
2006-07-25 05:51:23 +02:00
</row>
2020-05-14 05:03:39 +02:00
2006-07-25 05:51:23 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>is_dst</structfield> <type>bool</type>
</para>
<para>
True if currently observing daylight savings
</para></entry>
2006-07-25 05:51:23 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2003-10-18 00:38:20 +02:00
<sect1 id="view-pg-user">
<title><structname>pg_user</structname></title>
<indexterm zone="view-pg-user">
<primary>pg_user</primary>
</indexterm>
<para>
The view <structname>pg_user</structname> provides access to
information about database users. This is simply a publicly
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
readable view of
2005-06-28 07:09:14 +02:00
<link linkend="view-pg-shadow"><structname>pg_shadow</structname></link>
2003-10-18 00:38:20 +02:00
that blanks out the password field.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_user</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usename</structfield> <type>name</type>
</para>
<para>
User name
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usesysid</structfield> <type>oid</type>
</para>
<para>
ID of this user
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usecreatedb</structfield> <type>bool</type>
</para>
<para>
User can create databases
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usesuper</structfield> <type>bool</type>
</para>
<para>
User is a superuser
</para></entry>
2003-10-18 00:38:20 +02: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>userepl</structfield> <type>bool</type>
</para>
<para>
2012-04-06 22:54:27 +02:00
User can initiate streaming replication and put the system in and
out of backup mode.
2020-05-14 05:03:39 +02:00
</para></entry>
2012-04-06 22:54:27 +02: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>usebypassrls</structfield> <type>bool</type>
</para>
<para>
2015-10-04 02:19:57 +02:00
User 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>
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>passwd</structfield> <type>text</type>
</para>
<para>
Not the password (always reads as <literal>********</literal>)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>valuntil</structfield> <type>timestamptz</type>
</para>
<para>
Password expiry time (only used for password authentication)
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>useconfig</structfield> <type>text[]</type>
</para>
<para>
Session defaults for run-time configuration variables
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2008-12-19 17:25:19 +01:00
<sect1 id="view-pg-user-mappings">
<title><structname>pg_user_mappings</structname></title>
<indexterm zone="view-pg-user-mappings">
<primary>pg_user_mappings</primary>
</indexterm>
<para>
The view <structname>pg_user_mappings</structname> provides access
to information about user mappings. This is essentially a publicly
readable view of
<link linkend="catalog-pg-user-mapping"><structname>pg_user_mapping</structname></link>
that leaves out the options field if the user has no rights to use
it.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_user_mappings</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>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>umid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-user-mapping"><structname>pg_user_mapping</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the user mapping
</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>srvid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.<structfield>oid</structfield>)
</para>
<para>
2008-12-19 17:25:19 +01:00
The OID of the foreign server that contains this mapping
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>srvname</structfield> <type>name</type>
(references <link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.<structfield>srvname</structfield>)
</para>
<para>
2008-12-19 17:25:19 +01:00
Name of the foreign server
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>umuser</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the local role being mapped, 0 if the user mapping is public
</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>usename</structfield> <type>name</type>
</para>
<para>
Name of the local user to be mapped
</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>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>
2008-12-19 17:25:19 +01:00
</row>
</tbody>
</tgroup>
</table>
2017-08-07 16:09:28 +02:00
<para>
To protect password information stored as a user mapping option,
the <structfield>umoptions</structfield> column will read as null
unless one of the following applies:
<itemizedlist>
<listitem>
<para>
current user is the user being mapped, and owns the server or
2017-10-09 03:44:17 +02:00
holds <literal>USAGE</literal> privilege on it
2017-08-07 16:09:28 +02:00
</para>
</listitem>
<listitem>
<para>
2017-10-09 03:44:17 +02:00
current user is the server owner and mapping is for <literal>PUBLIC</literal>
2017-08-07 16:09:28 +02:00
</para>
</listitem>
<listitem>
<para>
current user is a superuser
</para>
</listitem>
</itemizedlist>
</para>
2008-12-19 17:25:19 +01:00
</sect1>
2003-10-18 00:38:20 +02:00
<sect1 id="view-pg-views">
<title><structname>pg_views</structname></title>
<indexterm zone="view-pg-views">
<primary>pg_views</primary>
</indexterm>
<para>
The view <structname>pg_views</structname> provides access to
useful information about each view in the database.
</para>
<table>
2017-10-09 03:44:17 +02:00
<title><structname>pg_views</structname> Columns</title>
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
2003-10-18 00:38:20 +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>
2003-10-18 00:38:20 +02:00
</row>
</thead>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<tbody>
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>nspname</structfield>)
</para>
<para>
Name of schema containing view
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>viewname</structfield> <type>name</type>
(references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relname</structfield>)
</para>
<para>
Name of view
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>viewowner</structfield> <type>name</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>rolname</structfield>)
</para>
<para>
Name of view's owner
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
2020-05-14 05:03:39 +02:00
2003-10-18 00:38:20 +02:00
<row>
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>definition</structfield> <type>text</type>
</para>
<para>
2020-09-03 13:15:53 +02:00
View definition (a reconstructed <xref linkend="sql-select"/> query)
2020-05-14 05:03:39 +02:00
</para></entry>
2003-10-18 00:38:20 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
2000-11-29 21:15:59 +01:00
</chapter>