rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/doc/src/sgml/catalogs.sgml

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

9728 lines
328 KiB
Plaintext
Raw Normal View History

Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
<!-- doc/src/sgml/catalogs.sgml -->
Rewrite system catalog documentation man page in DocBook with more recent information.
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.
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Normally, one should not change the system catalogs by hand, there
doc: Update wording about direct system catalog manipulation It was previously suggested that "esoteric" operations such as creating a new access method would require direct manipulation of the system catalogs, but that example has gone away, and I can't think of a new one to replace it, so just put in some weasel wording.
2016-06-07 20:15:42 +02:00
are normally SQL commands to do that. (For example, <command>CREATE
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
DATABASE</command> inserts a row into the
Replace "--" and "---" with "&mdash;" as appropriate, for better-looking output.
2004-11-15 07:32:15 +01:00
<structname>pg_database</structname> catalog &mdash; and actually
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
creates the database on disk.) There are some exceptions for
doc: Update wording about direct system catalog manipulation It was previously suggested that "esoteric" operations such as creating a new access method would require direct manipulation of the system catalogs, but that example has gone away, and I can't think of a new one to replace it, so just put in some weasel wording.
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.
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
</para>
<sect1 id="catalogs-overview">
<title>Overview</title>
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="catalog-table"/> lists the system catalogs.
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
More detailed documentation of each catalog follows below.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
- Link the entries in the table to the catalog heading - Wrap them in the <database class="table"> tags, since thats what they are (no markup rules for this, so it inherits from parent -- no style change) - Mention that pg_database, pg_shadow, and pg_group are global, and the rest are local to the specific DB. (I believe this is correct). > Works for me, though I suppose we could explain what the exceptions are > like in general terms. Perhaps something like > > 'Most system catalogs are copied from the template database during > database creation, and are thereafter database-specific. A few > catalogs are physically shared across all databases in an installation; > these are marked in the descriptions of the individual catalogs.' Ok, new patch. Rod Taylor
2002-10-14 06:29:23 +02:00
<para>
Most system catalogs are copied from the template database during
Add better markup and improve some text here and there.
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;
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
these are noted in the descriptions of the individual catalogs.
- Link the entries in the table to the catalog heading - Wrap them in the <database class="table"> tags, since thats what they are (no markup rules for this, so it inherits from parent -- no style change) - Mention that pg_database, pg_shadow, and pg_group are global, and the rest are local to the specific DB. (I believe this is correct). > Works for me, though I suppose we could explain what the exceptions are > like in general terms. Perhaps something like > > 'Most system catalogs are copied from the template database during > database creation, and are thereafter database-specific. A few > catalogs are physically shared across all databases in an installation; > these are marked in the descriptions of the individual catalogs.' Ok, new patch. Rod Taylor
2002-10-14 06:29:23 +02:00
</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<table id="catalog-table">
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-aggregate"><structname>pg_aggregate</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>aggregate functions</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-am"><structname>pg_am</structname></link></entry>
Fix some documentation about access methods Author: Guillaume Lelarge Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com
2019-05-29 17:37:37 +02:00
<entry>relation access methods</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-amop"><structname>pg_amop</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>access method operators</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-amproc"><structname>pg_amproc</structname></link></entry>
doc: Update uses of the word "procedure" Historically, the term procedure was used as a synonym for function in Postgres/PostgreSQL. Now we have procedures as separate objects from functions, so we need to clean up the documentation to not mix those terms. In particular, mentions of "trigger procedures" are changed to "trigger functions", and access method "support procedures" are changed to "support functions". (The latter already used FUNCTION in the SQL syntax anyway.) Also, the terminology in the SPI chapter has been cleaned up. A few tests, examples, and code comments are also adjusted to be consistent with documentation changes, but not everything. Reported-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>
2018-08-15 17:01:39 +02:00
<entry>access method support functions</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-attrdef"><structname>pg_attrdef</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>column default values</entry>
</row>
<row>
Add better markup and improve some text here and there.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-cast"><structname>pg_cast</structname></link></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry>casts (data type conversions)</entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-class"><structname>pg_class</structname></link></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>tables, indexes, sequences, views (<quote>relations</quote>)</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
<row>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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>
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
</row>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-conversion"><structname>pg_conversion</structname></link></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry>encoding conversion information</entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-database"><structname>pg_database</structname></link></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<entry>databases within this database cluster</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Move pg_db_role_setting docs to correct place in alphabetical order.
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>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-depend"><structname>pg_depend</structname></link></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<entry>dependencies between database objects</entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-description"><structname>pg_description</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>descriptions or comments on database objects</entry>
</row>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
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>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
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>
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-index"><structname>pg_index</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>additional index information</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-inherits"><structname>pg_inherits</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>table inheritance hierarchy</entry>
</row>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-language"><structname>pg_language</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>languages for writing functions</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-largeobject"><structname>pg_largeobject</structname></link></entry>
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link></entry>
<entry>schemas</entry>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link></entry>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<entry>access method operator classes</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>operators</entry>
</row>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
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>
Allow granting SET and ALTER SYSTEM privileges on GUC parameters. This patch allows "PGC_SUSET" parameters to be set by non-superusers if they have been explicitly granted the privilege to do so. The privilege to perform ALTER SYSTEM SET/RESET on a specific parameter can also be granted. Such privileges are cluster-wide, not per database. They are tracked in a new shared catalog, pg_parameter_acl. Granting and revoking these new privileges works as one would expect. One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege --- one could wish that those were handled by a revocable grant to PUBLIC, but they are not, because we couldn't make it robust enough for GUCs defined by extensions. Mark Dilger, reviewed at various times by Andrew Dunstan, Robert Haas, Joshua Brindle, and myself Discussion: https://postgr.es/m/3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com
2022-04-06 19:24:33 +02:00
<row>
<entry><link linkend="catalog-pg-parameter-acl"><structname>pg_parameter_acl</structname></link></entry>
<entry>configuration parameters for which privileges have been granted</entry>
</row>
Create the pg_pltemplate system catalog to hold template information for procedural languages. This replaces the hard-wired table I had originally proposed as a stopgap solution. For the moment, the initial contents only include languages shipped with the core distribution.
2005-09-08 22:07:42 +02:00
<row>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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>
Create the pg_pltemplate system catalog to hold template information for procedural languages. This replaces the hard-wired table I had originally proposed as a stopgap solution. For the moment, the initial contents only include languages shipped with the core distribution.
2005-09-08 22:07:42 +02:00
</row>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>functions and procedures</entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
<entry><link linkend="catalog-pg-publication"><structname>pg_publication</structname></link></entry>
<entry>publications for logical replication</entry>
</row>
Allow publishing the tables of schema. A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows one or more schemas to be specified, whose tables are selected by the publisher for sending the data to the subscriber. The new syntax allows specifying both the tables and schemas. For example: CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2; OR ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2; A new system table "pg_publication_namespace" has been added, to maintain the schemas that the user wants to publish through the publication. Modified the output plugin (pgoutput) to publish the changes if the relation is part of schema publication. Updates pg_dump to identify and dump schema publications. Updates the \d family of commands to display schema publications and \dRp+ variant will now display associated schemas if any. Author: Vignesh C, Hou Zhijie, Amit Kapila Syntax-Suggested-by: Tom Lane, Alvaro Herrera Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger Tested-by: Haiying Tang Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
<row>
<entry><link linkend="catalog-pg-publication-namespace"><structname>pg_publication_namespace</structname></link></entry>
<entry>schema to publication mapping</entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
<entry><link linkend="catalog-pg-publication-rel"><structname>pg_publication_rel</structname></link></entry>
<entry>relation to publication mapping</entry>
</row>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
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>
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
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>
Introduce replication slots. Replication slots are a crash-safe data structure which can be created on either a master or a standby to prevent premature removal of write-ahead log segments needed by a standby, as well as (with hot_standby_feedback=on) pruning of tuples whose removal would cause replication conflicts. Slots have some advantages over existing techniques, as explained in the documentation. In a few places, we refer to the type of replication slots introduced by this patch as "physical" slots, because forthcoming patches for logical decoding will also have slots, but with somewhat different properties. Andres Freund and Robert Haas
2014-02-01 04:45:17 +01:00
</row>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
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>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
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>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
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>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
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>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link></entry>
<entry>planner statistics</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
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>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
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>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-trigger"><structname>pg_trigger</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>triggers</entry>
</row>
Add catalogs.sgml documentation for text search catalogs.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><link linkend="catalog-pg-type"><structname>pg_type</structname></link></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>data types</entry>
</row>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-aggregate">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_aggregate</structname></title>
<indexterm zone="catalog-pg-aggregate">
<primary>pg_aggregate</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_aggregate</structname> stores information about
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
aggregate functions. An aggregate function is a function that
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
operates on a set of values (typically one column from each row
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
<function>max</function>. Each entry in
<structname>pg_aggregate</structname> is an extension of an entry
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_aggregate</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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:
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Improve documentation for combine functions. David Rowley
2016-03-24 17:59:18 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Improve documentation for combine functions. David Rowley
2016-03-24 17:59:18 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Allow aggregate transition states to be serialized and deserialized. This is necessary infrastructure for supporting parallel aggregation for aggregates whose transition type is "internal". Such values can't be passed between cooperating processes, because they are just pointers. David Rowley, reviewed by Tomas Vondra and by me.
2016-03-29 21:04:05 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow aggregate transition states to be serialized and deserialized. This is necessary infrastructure for supporting parallel aggregation for aggregates whose transition type is "internal". Such values can't be passed between cooperating processes, because they are just pointers. David Rowley, reviewed by Tomas Vondra and by me.
2016-03-29 21:04:05 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Allow aggregate transition states to be serialized and deserialized. This is necessary infrastructure for supporting parallel aggregation for aggregates whose transition type is "internal". Such values can't be passed between cooperating processes, because they are just pointers. David Rowley, reviewed by Tomas Vondra and by me.
2016-03-29 21:04:05 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow aggregate transition states to be serialized and deserialized. This is necessary infrastructure for supporting parallel aggregation for aggregates whose transition type is "internal". Such values can't be passed between cooperating processes, because they are just pointers. David Rowley, reviewed by Tomas Vondra and by me.
2016-03-29 21:04:05 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add aggsortop column to pg_aggregate, so that MIN/MAX optimization can be supported for all datatypes. Add CREATE AGGREGATE and pg_dump support too. Add specialized min/max aggregates for bpchar, instead of depending on text's min/max, because otherwise the possible use of bpchar indexes cannot be recognized. initdb forced because of catalog changes.
2005-04-12 06:26:34 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add aggsortop column to pg_aggregate, so that MIN/MAX optimization can be supported for all datatypes. Add CREATE AGGREGATE and pg_dump support too. Add specialized min/max aggregates for bpchar, instead of depending on text's min/max, because otherwise the possible use of bpchar indexes cannot be recognized. initdb forced because of catalog changes.
2005-04-12 06:26:34 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Allow aggregates to provide estimates of their transition state data size. Formerly the planner had a hard-wired rule of thumb for guessing the amount of space consumed by an aggregate function's transition state data. This estimate is critical to deciding whether it's OK to use hash aggregation, and in many situations the built-in estimate isn't very good. This patch adds a column to pg_aggregate wherein a per-aggregate estimate can be provided, overriding the planner's default, and infrastructure for setting the column via CREATE AGGREGATE. It may be that additional smarts will be required in future, perhaps even a per-aggregate estimation function. But this is already a step forward. This is extracted from a larger patch to improve the performance of numeric and int8 aggregates. I (tgl) thought it was worth reviewing and committing this infrastructure separately. In this commit, all built-in aggregates are given aggtransspace = 0, so no behavior should change. Hadi Moshayedi, reviewed by Pavel Stehule and Tomas Vondra
2013-11-16 22:03:40 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow aggregates to provide estimates of their transition state data size. Formerly the planner had a hard-wired rule of thumb for guessing the amount of space consumed by an aggregate function's transition state data. This estimate is critical to deciding whether it's OK to use hash aggregation, and in many situations the built-in estimate isn't very good. This patch adds a column to pg_aggregate wherein a per-aggregate estimate can be provided, overriding the planner's default, and infrastructure for setting the column via CREATE AGGREGATE. It may be that additional smarts will be required in future, perhaps even a per-aggregate estimation function. But this is already a step forward. This is extracted from a larger patch to improve the performance of numeric and int8 aggregates. I (tgl) thought it was worth reviewing and committing this infrastructure separately. In this commit, all built-in aggregates are given aggtransspace = 0, so no behavior should change. Hadi Moshayedi, reviewed by Pavel Stehule and Tomas Vondra
2013-11-16 22:03:40 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
The initial value of the transition state. This is a text
Fix handling of pg_type.typdefault per bug report from Dave Blasby. If there's anyone out there who's actually using datatype-defined default values, this will be an incompatible change in behavior ... but the old behavior was so broken that I doubt anyone was using it.
2001-09-06 04:07:42 +02:00
field containing the initial value in its external string
Spell and markup checking
2010-08-17 06:37:21 +02:00
representation. If this field is null, the transition state
value starts out null.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Create infrastructure for moving-aggregate optimization. Until now, when executing an aggregate function as a window function within a window with moving frame start (that is, any frame start mode except UNBOUNDED PRECEDING), we had to recalculate the aggregate from scratch each time the frame head moved. This patch allows an aggregate definition to include an alternate "moving aggregate" implementation that includes an inverse transition function for removing rows from the aggregate's running state. As long as this can be done successfully, runtime is proportional to the total number of input rows, rather than to the number of input rows times the average frame length. This commit includes the core infrastructure, documentation, and regression tests using user-defined aggregates. Follow-on commits will update some of the built-in aggregates to use this feature. David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional hacking by me
2014-04-12 17:58:53 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
command. See <xref linkend="xaggr"/> for more information about
Change the parameter_types column of the pg_prepared_statements to be an array of regtype, rather than an array of OIDs. This is likely to be more useful to user, and the type OID can easily be obtained by casting a regtype value to OID. Per suggestion from Tom. Update the documentation and regression tests, and bump the catversion.
2006-01-16 19:15:31 +01:00
writing aggregate functions and the meaning of the transition
functions, etc.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<sect1 id="catalog-pg-am">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_am</structname></title>
<indexterm zone="catalog-pg-am">
<primary>pg_am</primary>
</indexterm>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<para>
Add SQL-accessible functions for inspecting index AM properties. Per discussion, we should provide such functions to replace the lost ability to discover AM properties by inspecting pg_am (cf commit 65c5fcd35). The added functionality is also meant to displace any code that was looking directly at pg_index.indoption, since we'd rather not believe that the bit meanings in that field are part of any client API contract. As future-proofing, define the SQL API to not assume that properties that are currently AM-wide or index-wide will remain so unless they logically must be; instead, expose them only when inquiring about a specific index or even specific index column. Also provide the ability for an index AM to override the behavior. In passing, document pg_am.amtype, overlooked in commit 473b93287. Andrew Gierth, with kibitzing by me and others Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>
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.
table: docs: fix typos and grammar. Author: Justin Pryzby Discussion: https://postgr.es/m/20190404055138.GA24864@telsasoft.com
2019-04-05 18:45:59 +02:00
Currently, only tables and indexes have access methods. The requirements for table
tableam: basic documentation. This adds documentation about the user oriented parts of table access methods (i.e. the default_table_access_method GUC and the USING clause for CREATE TABLE etc), adds a basic chapter about the table access method interface, and adds a note to storage.sgml that it's contents don't necessarily apply for non-builtin AMs. Author: Haribabu Kommi and Andres Freund Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
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.
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_am</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Code review for FILLFACTOR patch. Change WITH grammar as per earlier discussion (including making def_arg allow reserved words), add missed opt_definition for UNIQUE case. Put the reloptions support code in a less random place (I chose to make a new file access/common/reloptions.c). Eliminate header inclusion creep. Make the index options functions safely user-callable (seems like client apps might like to be able to test validity of options before trying to make an index). Reduce overhead for normal case with no options by allowing rd_options to be NULL. Fix some unmaintainably klugy code, including getting rid of Natts_pg_class_fixed at long last. Some stylistic cleanup too, and pay attention to keeping comments in sync with code. Documentation still needs work, though I did fix the omissions in catalogs.sgml and indexam.sgml.
2006-07-04 00:45:41 +02:00
</row>
Add SQL-accessible functions for inspecting index AM properties. Per discussion, we should provide such functions to replace the lost ability to discover AM properties by inspecting pg_am (cf commit 65c5fcd35). The added functionality is also meant to displace any code that was looking directly at pg_index.indoption, since we'd rather not believe that the bit meanings in that field are part of any client API contract. As future-proofing, define the SQL API to not assume that properties that are currently AM-wide or index-wide will remain so unless they logically must be; instead, expose them only when inquiring about a specific index or even specific index column. Also provide the ability for an index AM to override the behavior. In passing, document pg_am.amtype, overlooked in commit 473b93287. Andrew Gierth, with kibitzing by me and others Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>
2016-08-14 00:31:14 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
tableam: basic documentation. This adds documentation about the user oriented parts of table access methods (i.e. the default_table_access_method GUC and the USING clause for CREATE TABLE etc), adds a basic chapter about the table access method interface, and adds a note to storage.sgml that it's contents don't necessarily apply for non-builtin AMs. Author: Haribabu Kommi and Andres Freund Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
2019-04-04 02:37:00 +02:00
<literal>t</literal> = table (including materialized views),
<literal>i</literal> = index.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add SQL-accessible functions for inspecting index AM properties. Per discussion, we should provide such functions to replace the lost ability to discover AM properties by inspecting pg_am (cf commit 65c5fcd35). The added functionality is also meant to displace any code that was looking directly at pg_index.indoption, since we'd rather not believe that the bit meanings in that field are part of any client API contract. As future-proofing, define the SQL API to not assume that properties that are currently AM-wide or index-wide will remain so unless they logically must be; instead, expose them only when inquiring about a specific index or even specific index column. Also provide the ability for an index AM to override the behavior. In passing, document pg_am.amtype, overlooked in commit 473b93287. Andrew Gierth, with kibitzing by me and others Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>
2016-08-14 00:31:14 +02:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</tbody>
</tgroup>
</table>
Add SQL-accessible functions for inspecting index AM properties. Per discussion, we should provide such functions to replace the lost ability to discover AM properties by inspecting pg_am (cf commit 65c5fcd35). The added functionality is also meant to displace any code that was looking directly at pg_index.indoption, since we'd rather not believe that the bit meanings in that field are part of any client API contract. As future-proofing, define the SQL API to not assume that properties that are currently AM-wide or index-wide will remain so unless they logically must be; instead, expose them only when inquiring about a specific index or even specific index column. Also provide the ability for an index AM to override the behavior. In passing, document pg_am.amtype, overlooked in commit 473b93287. Andrew Gierth, with kibitzing by me and others Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>
2016-08-14 00:31:14 +02:00
<note>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Before <productname>PostgreSQL</productname> 9.6, <structname>pg_am</structname>
Add SQL-accessible functions for inspecting index AM properties. Per discussion, we should provide such functions to replace the lost ability to discover AM properties by inspecting pg_am (cf commit 65c5fcd35). The added functionality is also meant to displace any code that was looking directly at pg_index.indoption, since we'd rather not believe that the bit meanings in that field are part of any client API contract. As future-proofing, define the SQL API to not assume that properties that are currently AM-wide or index-wide will remain so unless they logically must be; instead, expose them only when inquiring about a specific index or even specific index column. Also provide the ability for an index AM to override the behavior. In passing, document pg_am.amtype, overlooked in commit 473b93287. Andrew Gierth, with kibitzing by me and others Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
method properties; see <xref linkend="functions-info-catalog-table"/>.
Add SQL-accessible functions for inspecting index AM properties. Per discussion, we should provide such functions to replace the lost ability to discover AM properties by inspecting pg_am (cf commit 65c5fcd35). The added functionality is also meant to displace any code that was looking directly at pg_index.indoption, since we'd rather not believe that the bit meanings in that field are part of any client API contract. As future-proofing, define the SQL API to not assume that properties that are currently AM-wide or index-wide will remain so unless they logically must be; instead, expose them only when inquiring about a specific index or even specific index column. Also provide the ability for an index AM to override the behavior. In passing, document pg_am.amtype, overlooked in commit 473b93287. Andrew Gierth, with kibitzing by me and others Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>
2016-08-14 00:31:14 +02:00
</para>
</note>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</sect1>
<sect1 id="catalog-pg-amop">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_amop</structname></title>
<indexterm zone="catalog-pg-amop">
<primary>pg_amop</primary>
</indexterm>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<para>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
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
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
row for each operator that is a member of an operator family. A family
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
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.)
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_amop</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</tbody>
</tgroup>
</table>
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
A <quote>search</quote> operator entry indicates that an index of this operator
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
family can be searched to find all rows satisfying
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>WHERE</literal>
<replaceable>indexed_column</replaceable>
<replaceable>operator</replaceable>
<replaceable>constant</replaceable>.
doc: Spell checking
2014-07-17 04:20:15 +02:00
Obviously, such an operator must return <type>boolean</type>, and its left-hand input
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
type must match the index's column data type.
</para>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
An <quote>ordering</quote> operator entry indicates that an index of this
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
operator family can be scanned to return rows in the order represented by
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>ORDER BY</literal>
<replaceable>indexed_column</replaceable>
<replaceable>operator</replaceable>
<replaceable>constant</replaceable>.
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The exact semantics of the <literal>ORDER BY</literal> are specified by the
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
<structfield>amopsortfamily</structfield> column, which must reference
doc: Spell checking
2014-07-17 04:20:15 +02:00
a B-tree operator family for the operator's result type.
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
</para>
<note>
<para>
At present, it's assumed that the sort order for an ordering operator
doc: Spell checking
2014-07-17 04:20:15 +02:00
is the default for the referenced operator family, i.e., <literal>ASC NULLS
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
LAST</literal>. This might someday be relaxed by adding additional columns
Create the system catalog infrastructure needed for KNNGIST. This commit adds columns amoppurpose and amopsortfamily to pg_amop, and column amcanorderbyop to pg_am. For the moment all the entries in amcanorderbyop are "false", since the underlying support isn't there yet. Also, extend the CREATE OPERATOR CLASS/ALTER OPERATOR FAMILY commands with [ FOR SEARCH | FOR ORDER BY sort_operator_family ] clauses to allow the new columns of pg_amop to be populated, and create pg_dump support for dumping that information. I also added some documentation, although it's perhaps a bit premature given that the feature doesn't do anything useful yet. Teodor Sigaev, Robert Haas, Tom Lane
2010-11-24 20:20:39 +01:00
to specify sort options explicitly.
</para>
</note>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
An entry's <structfield>amopmethod</structfield> must match the
Fix inconsistent markups in catalogs.sgml Some fields related to pg_opclass and pg_opfamily were using incorrect markups, listing them as structname instead of structfield. Author: Fabien Coelho Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2006210903560.859381@pseudo
2020-06-22 06:40:04 +02:00
<structfield>opfmethod</structfield> of its containing operator family (including
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>amopmethod</structfield> here is an intentional denormalization of the
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
catalog structure for performance reasons). Also,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
referenced <link linkend="catalog-pg-operator"><structname>pg_operator</structname></link> entry.
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</para>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</sect1>
<sect1 id="catalog-pg-amproc">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_amproc</structname></title>
<indexterm zone="catalog-pg-amproc">
<primary>pg_amproc</primary>
</indexterm>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<para>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
The catalog <structname>pg_amproc</structname> stores information about
doc: Update uses of the word "procedure" Historically, the term procedure was used as a synonym for function in Postgres/PostgreSQL. Now we have procedures as separate objects from functions, so we need to clean up the documentation to not mix those terms. In particular, mentions of "trigger procedures" are changed to "trigger functions", and access method "support procedures" are changed to "support functions". (The latter already used FUNCTION in the SQL syntax anyway.) Also, the terminology in the SPI chapter has been cleaned up. A few tests, examples, and code comments are also adjusted to be consistent with documentation changes, but not everything. Reported-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>
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.
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</para>
<table>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_amproc</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Cross-data-type comparisons are now indexable by btrees, pursuant to my pghackers proposal of 8-Nov. All the existing cross-type comparison operators (int2/int4/int8 and float4/float8) have appropriate support. The original proposal of storing the right-hand-side datatype as part of the primary key for pg_amop and pg_amproc got modified a bit in the event; it is easier to store zero as the 'default' case and only store a nonzero when the operator is actually cross-type. Along the way, remove the long-since-defunct bigbox_ops operator class.
2003-11-12 22:15:59 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
</tbody>
</tgroup>
</table>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<para>
The usual interpretation of the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>amproclefttype</structfield> and <structfield>amprocrighttype</structfield> fields
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
is that they identify the left and right input types of the operator(s)
doc: Update uses of the word "procedure" Historically, the term procedure was used as a synonym for function in Postgres/PostgreSQL. Now we have procedures as separate objects from functions, so we need to clean up the documentation to not mix those terms. In particular, mentions of "trigger procedures" are changed to "trigger functions", and access method "support procedures" are changed to "support functions". (The latter already used FUNCTION in the SQL syntax anyway.) Also, the terminology in the SPI chapter has been cleaned up. A few tests, examples, and code comments are also adjusted to be consistent with documentation changes, but not everything. Reported-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>.
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</para>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-attrdef">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_attrdef</structname></title>
<indexterm zone="catalog-pg-attrdef">
<primary>pg_attrdef</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Improve description of pg_attrdef in documentation The reference to pg_attribute is switched to a link, which is more useful for the html documentation. The conditions under which a default value is defined for a given column are made more general. Author: Daniel Gustafsson Reviewed-by: Tom Lane Discussion: https://postgr.es/m/0E8748E3-8B7D-445E-9ABA-09DA5C7345CC@yesql.se
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_attrdef</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-attribute">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_attribute</structname></title>
<indexterm zone="catalog-pg-attribute">
<primary>pg_attribute</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_attribute</structname> stores information about
Rewrite system catalog documentation man page in DocBook with more recent information.
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
entries.)
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_attribute</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The data type of this column (zero for a dropped column)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
A copy of <literal>pg_type.typlen</literal> of this column's
type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
The number of the column. Ordinary columns are numbered from 1
docs: cleanup/remove/update references to OID column. I (Andres) missed these in 578b229718e8f. Author: Justin Pryzby, editorialized a bit by Andres Freund Reviewed-By: Daniel Verite, Andres Freund Discussion: https://postgr.es/m/20190408002847.GA904@telsasoft.com
2019-04-18 02:22:56 +02:00
up. System columns, such as <structfield>ctid</structfield>,
Spell and markup checking
2010-08-17 06:37:21 +02:00
have (arbitrary) negative numbers.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Spell checking, consistent terminology.
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
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
within the row
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
type-specific input functions and length coercion functions.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The value will generally be -1 for types that do not need <structfield>atttypmod</structfield>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Save a few bytes in pg_attribute Change the columns attndims, attstattarget, and attinhcount from int32 to int16, and reorder a bit. This saves some space (currently 4 bytes) in pg_attribute and tuple descriptors, which translates into small performance benefits and/or room for new columns in pg_attribute needed by future features. attndims and attinhcount are never realistically used with values larger than int16. Just to be sure, add some overflow checks. attstattarget is currently limited explicitly to 10000. For consistency, pg_constraint.coninhcount is also changed like attinhcount. Discussion: https://www.postgresql.org/message-id/flat/d07ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
2023-03-28 09:58:14 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attndims</structfield> <type>int2</type>
</para>
<para>
Number of dimensions, if the column is an array type; otherwise 0.
(Presently, the number of dimensions of an array is not enforced,
so any nonzero value effectively means <quote>it's an array</quote>.)
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
A copy of <literal>pg_type.typbyval</literal> of this column's type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Re-order pg_attribute columns to eliminate some padding space. Now that attcompression is just a char, there's a lot of wasted padding space after it. Move it into the group of char-wide columns to save a net of 4 bytes per pg_attribute entry. While we're at it, swap the order of attstorage and attalign to make for a more logical grouping of these columns. Also re-order actions in related code to match the new field ordering. This patch also fixes one outright bug: equalTupleDescs() failed to compare attcompression. That could, for example, cause relcache reload to fail to adopt a new value following a change. Michael Paquier and Tom Lane, per a gripe from Andres Freund. Discussion: https://postgr.es/m/20210517204803.iyk5wwvwgtjcmc5w@alap3.anarazel.de
2021-05-23 18:12:09 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attalign</structfield> <type>char</type>
</para>
<para>
A copy of <literal>pg_type.typalign</literal> of this column's type
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Normally a copy of <literal>pg_type.typstorage</literal> of this
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
column's type. For TOAST-able data types, this can be altered
Spell and markup checking
2010-08-17 06:37:21 +02:00
after column creation to control storage policy.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Re-order pg_attribute columns to eliminate some padding space. Now that attcompression is just a char, there's a lot of wasted padding space after it. Move it into the group of char-wide columns to save a net of 4 bytes per pg_attribute entry. While we're at it, swap the order of attstorage and attalign to make for a more logical grouping of these columns. Also re-order actions in related code to match the new field ordering. This patch also fixes one outright bug: equalTupleDescs() failed to compare attcompression. That could, for example, cause relcache reload to fail to adopt a new value following a change. Michael Paquier and Tom Lane, per a gripe from Andres Freund. Discussion: https://postgr.es/m/20210517204803.iyk5wwvwgtjcmc5w@alap3.anarazel.de
2021-05-23 18:12:09 +02:00
<structfield>attcompression</structfield> <type>char</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Rethink definition of pg_attribute.attcompression. Redefine '\0' (InvalidCompressionMethod) as meaning "if we need to compress, use the current setting of default_toast_compression". This allows '\0' to be a suitable default choice regardless of datatype, greatly simplifying code paths that initialize tupledescs and the like. It seems like a more user-friendly approach as well, because now the default compression choice doesn't migrate into table definitions, meaning that changing default_toast_compression is usually sufficient to flip an installation's behavior; one needn't tediously issue per-column ALTER SET COMPRESSION commands. Along the way, fix a few minor bugs and documentation issues with the per-column-compression feature. Adopt more robust APIs for SetIndexStorageProperties and GetAttributeCompression. Bump catversion because typical contents of attcompression will now be different. We could get away without doing that, but it seems better to ensure v14 installations all agree on this. (We already forced initdb for beta2, anyway.) Discussion: https://postgr.es/m/626613.1621787110@sss.pgh.pa.us
2021-05-27 19:24:24 +02:00
The current compression method of the column. Typically this is
<literal>'\0'</literal> to specify use of the current default setting
(see <xref linkend="guc-default-toast-compression"/>). Otherwise,
<literal>'p'</literal> selects pglz compression, while
<literal>'l'</literal> selects <productname>LZ4</productname>
compression. However, this field is ignored
whenever <structfield>attstorage</structfield> does not allow
compression.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attnotnull</structfield> <type>bool</type>
</para>
<para>
Catalog not-null constraints We now create contype='n' pg_constraint rows for not-null constraints. We propagate these constraints to other tables during operations such as adding inheritance relationships, creating and attaching partitions and creating tables LIKE other tables. We also spawn not-null constraints for inheritance child tables when their parents have primary keys. These related constraints mostly follow the well-known rules of conislocal and coninhcount that we have for CHECK constraints, with some adaptations: for example, as opposed to CHECK constraints, we don't match not-null ones by name when descending a hierarchy to alter it, instead matching by column name that they apply to. This means we don't require the constraint names to be identical across a hierarchy. For now, we omit them for system catalogs. Maybe this is worth reconsidering. We don't support NOT VALID nor DEFERRABLE clauses either; these can be added as separate features later (this patch is already large and complicated enough.) psql shows these constraints in \d+. pg_dump requires some ad-hoc hacks, particularly when dumping a primary key. We now create one "throwaway" not-null constraint for each column in the PK together with the CREATE TABLE command, and once the PK is created, all those throwaway constraints are removed. This avoids having to check each tuple for nullness when the dump restores the primary key creation. pg_upgrading from an older release requires a somewhat brittle procedure to create a constraint state that matches what would be created if the database were being created fresh in Postgres 17. I have tested all the scenarios I could think of, and it works correctly as far as I can tell, but I could have neglected weird cases. This patch has been very long in the making. The first patch was written by Bernd Helmle in 2010 to add a new pg_constraint.contype value ('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one was killed by the realization that we ought to use contype='c' instead: manufactured CHECK constraints. However, later SQL standard development, as well as nonobvious emergent properties of that design (mostly, failure to distinguish them from "normal" CHECK constraints as well as the performance implication of having to test the CHECK expression) led us to reconsider this choice, so now the current implementation uses contype='n' again. During Postgres 16 this had already been introduced by commit e056c557aef4, but there were some problems mainly with the pg_upgrade procedure that couldn't be fixed in reasonable time, so it was reverted. In 2016 Vitaly Burovoy also worked on this feature[1] but found no consensus for his proposed approach, which was claimed to be closer to the letter of the standard, requiring an additional pg_attribute column to track the OID of the not-null constraint for that column. [1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Author: Bernd Helmle <mailings@oopsware.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
This column is marked not-null, either by a not-null constraint
or a primary key.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-attrdef"><structname>pg_attrdef</structname></link> catalog that actually defines the
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
expression. (Check <structfield>attgenerated</structfield> to
determine whether this is a default or a generation expression.)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile. The default expression is evaluated at the time of the ALTER TABLE and the result stored in a new column (attmissingval) in pg_attribute, and a new column (atthasmissing) is set to true. Any existing row when fetched will be supplied with the attmissingval. New rows will have the supplied value or the default and so will never need the attmissingval. Any time the table is rewritten all the atthasmissing and attmissingval settings for the attributes are cleared, as they are no longer needed. The most visible code change from this is in heap_attisnull, which acquires a third TupleDesc argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley. Discussion: https://postgr.es/m/31e2e921-7002-4c27-59f5-51f08404c858@2ndQuadrant.com
2018-03-28 02:13:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile. The default expression is evaluated at the time of the ALTER TABLE and the result stored in a new column (attmissingval) in pg_attribute, and a new column (atthasmissing) is set to true. Any existing row when fetched will be supplied with the attmissingval. New rows will have the supplied value or the default and so will never need the attmissingval. Any time the table is rewritten all the atthasmissing and attmissingval settings for the attributes are cleared, as they are no longer needed. The most visible code change from this is in heap_attisnull, which acquires a third TupleDesc argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley. Discussion: https://postgr.es/m/31e2e921-7002-4c27-59f5-51f08404c858@2ndQuadrant.com
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile. The default expression is evaluated at the time of the ALTER TABLE and the result stored in a new column (attmissingval) in pg_attribute, and a new column (atthasmissing) is set to true. Any existing row when fetched will be supplied with the attmissingval. New rows will have the supplied value or the default and so will never need the attmissingval. Any time the table is rewritten all the atthasmissing and attmissingval settings for the attributes are cleared, as they are no longer needed. The most visible code change from this is in heap_attisnull, which acquires a third TupleDesc argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley. Discussion: https://postgr.es/m/31e2e921-7002-4c27-59f5-51f08404c858@2ndQuadrant.com
2018-03-28 02:13:52 +02:00
</row>
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Identity columns This is the SQL standard-conforming variant of PostgreSQL's serial columns. It fixes a few usability issues that serial columns have: - CREATE TABLE / LIKE copies default but refers to same sequence - cannot add/drop serialness with ALTER TABLE - dropping default does not drop sequence - need to grant separate privileges to sequence - other slight weirdnesses because serial is some kind of special macro Reviewed-by: Vitaly Burovoy <vitaly.burovoy@gmail.com>
2017-04-06 14:33:16 +02:00
</row>
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
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.)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
</row>
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
ignored by the parser and so cannot be accessed via SQL.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
ALTER TABLE DROP COLUMN works. Patch by Christopher Kings-Lynne, code review by Tom Lane. Remaining issues: functions that take or return tuple types are likely to break if one drops (or adds!) a column in the table defining the type. Need to think about what to do here. Along the way: some code review for recent COPY changes; mark system columns attnotnull = true where appropriate, per discussion a month ago.
2002-08-02 20:15:10 +02:00
</row>
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
be locally defined and inherited simultaneously.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Save a few bytes in pg_attribute Change the columns attndims, attstattarget, and attinhcount from int32 to int16, and reorder a bit. This saves some space (currently 4 bytes) in pg_attribute and tuple descriptors, which translates into small performance benefits and/or room for new columns in pg_attribute needed by future features. attndims and attinhcount are never realistically used with values larger than int16. Just to be sure, add some overflow checks. attstattarget is currently limited explicitly to 10000. For consistency, pg_constraint.coninhcount is also changed like attinhcount. Discussion: https://www.postgresql.org/message-id/flat/d07ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
2023-03-28 09:58:14 +02:00
<structfield>attinhcount</structfield> <type>int2</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType() with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
2008-07-30 19:05:05 +02:00
The number of direct ancestors this column has. A column with a
Spell and markup checking
2010-08-17 06:37:21 +02:00
nonzero number of ancestors cannot be dropped nor renamed.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add attisinherited column to pg_attribute; use it to guard against column additions, deletions, and renames that would let a child table get out of sync with its parent. Patch by Alvaro Herrera, with some kibitzing by Tom Lane.
2002-08-30 21:23:20 +02:00
</row>
doc: Update catalog documentation for attstattarget nullable Fixup for 4f622503d6.
2024-01-14 07:46:01 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attcollation</structfield> <type>oid</type>
(references <link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.<structfield>oid</structfield>)
</para>
<para>
The defined collation of the column, or zero if the column is
not of a collatable data type
</para></entry>
</row>
Save a few bytes in pg_attribute Change the columns attndims, attstattarget, and attinhcount from int32 to int16, and reorder a bit. This saves some space (currently 4 bytes) in pg_attribute and tuple descriptors, which translates into small performance benefits and/or room for new columns in pg_attribute needed by future features. attndims and attinhcount are never realistically used with values larger than int16. Just to be sure, add some overflow checks. attstattarget is currently limited explicitly to 10000. For consistency, pg_constraint.coninhcount is also changed like attinhcount. Discussion: https://www.postgresql.org/message-id/flat/d07ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
2023-03-28 09:58:14 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>attstattarget</structfield> <type>int2</type>
</para>
<para>
<structfield>attstattarget</structfield> controls the level of detail
of statistics accumulated for this column by
<link linkend="sql-analyze"><command>ANALYZE</command></link>.
A zero value indicates that no statistics should be collected.
doc: Update catalog documentation for attstattarget nullable Fixup for 4f622503d6.
2024-01-14 07:46:01 +01:00
A null value says to use the system default statistics target.
Save a few bytes in pg_attribute Change the columns attndims, attstattarget, and attinhcount from int32 to int16, and reorder a bit. This saves some space (currently 4 bytes) in pg_attribute and tuple descriptors, which translates into small performance benefits and/or room for new columns in pg_attribute needed by future features. attndims and attinhcount are never realistically used with values larger than int16. Just to be sure, add some overflow checks. attstattarget is currently limited explicitly to 10000. For consistency, pg_constraint.coninhcount is also changed like attinhcount. Discussion: https://www.postgresql.org/message-id/flat/d07ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
2023-03-28 09:58:14 +02:00
The exact meaning of positive values is data type-dependent.
For scalar data types, <structfield>attstattarget</structfield>
is both the target number of <quote>most common values</quote>
to collect, and the target number of histogram bins to create.
</para></entry>
</row>
Allow configurable LZ4 TOAST compression. There is now a per-column COMPRESSION option which can be set to pglz (the default, and the only option in up until now) or lz4. Or, if you like, you can set the new default_toast_compression GUC to lz4, and then that will be the default for new table columns for which no value is specified. We don't have lz4 support in the PostgreSQL code, so to use lz4 compression, PostgreSQL must be built --with-lz4. In general, TOAST compression means compression of individual column values, not the whole tuple, and those values can either be compressed inline within the tuple or compressed and then stored externally in the TOAST table, so those properties also apply to this feature. Prior to this commit, a TOAST pointer has two unused bits as part of the va_extsize field, and a compessed datum has two unused bits as part of the va_rawsize field. These bits are unused because the length of a varlena is limited to 1GB; we now use them to indicate the compression type that was used. This means we only have bit space for 2 more built-in compresison types, but we could work around that problem, if necessary, by introducing a new vartag_external value for any further types we end up wanting to add. Hopefully, it won't be too important to offer a wide selection of algorithms here, since each one we add not only takes more coding but also adds a build dependency for every packager. Nevertheless, it seems worth doing at least this much, because LZ4 gets better compression than PGLZ with less CPU usage. It's possible for LZ4-compressed datums to leak into composite type values stored on disk, just as it is for PGLZ. It's also possible for LZ4-compressed attributes to be copied into a different table via SQL commands such as CREATE TABLE AS or INSERT .. SELECT. It would be expensive to force such values to be decompressed, so PostgreSQL has never done so. For the same reasons, we also don't force recompression of already-compressed values even if the target table prefers a different compression method than was used for the source data. These architectural decisions are perhaps arguable but revisiting them is well beyond the scope of what seemed possible to do as part of this project. However, it's relatively cheap to recompress as part of VACUUM FULL or CLUSTER, so this commit adjusts those commands to do so, if the configured compression method of the table happens not to match what was used for some column value stored therein. Dilip Kumar. The original patches on which this work was based were written by Ildus Kurbangaliev, and those were patches were based on even earlier work by Nikita Glukhov, but the design has since changed very substantially, since allow a potentially large number of compression methods that could be added and dropped on a running system proved too problematic given some of the architectural issues mentioned above; the choice of which specific compression method to add first is now different; and a lot of the code has been heavily refactored. More recently, Justin Przyby helped quite a bit with testing and reviewing and this version also includes some code contributions from him. Other design input and review from Tomas Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander Korotkov, and me. Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 20:10:38 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<structfield>attacl</structfield> <type>aclitem[]</type>
</para>
<para>
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
Column-level access privileges, if any have been granted specifically
on this column
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
</row>
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace ALTER TABLE ... SET STATISTICS DISTINCT with a more general mechanism. Attributes can now have options, just as relations and tablespaces do, and the reloptions code is used to parse, validate, and store them. For simplicity and because these options are not performance critical, we store them in a separate cache rather than the main relcache. Thanks to Alex Hunsaker for the review.
2010-01-22 17:40:19 +01:00
</row>
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Attribute-level foreign data wrapper options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Allow per-column foreign data wrapper options. Shigeru Hanada, with fairly minor editing by me.
2011-08-05 19:24:03 +02:00
</row>
Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile. The default expression is evaluated at the time of the ALTER TABLE and the result stored in a new column (attmissingval) in pg_attribute, and a new column (atthasmissing) is set to true. Any existing row when fetched will be supplied with the attmissingval. New rows will have the supplied value or the default and so will never need the attmissingval. Any time the table is rewritten all the atthasmissing and attmissingval settings for the attributes are cleared, as they are no longer needed. The most visible code change from this is in heap_attisnull, which acquires a third TupleDesc argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley. Discussion: https://postgr.es/m/31e2e921-7002-4c27-59f5-51f08404c858@2ndQuadrant.com
2018-03-28 02:13:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile. The default expression is evaluated at the time of the ALTER TABLE and the result stored in a new column (attmissingval) in pg_attribute, and a new column (atthasmissing) is set to true. Any existing row when fetched will be supplied with the attmissingval. New rows will have the supplied value or the default and so will never need the attmissingval. Any time the table is rewritten all the atthasmissing and attmissingval settings for the attributes are cleared, as they are no longer needed. The most visible code change from this is in heap_attisnull, which acquires a third TupleDesc argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley. Discussion: https://postgr.es/m/31e2e921-7002-4c27-59f5-51f08404c858@2ndQuadrant.com
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile. The default expression is evaluated at the time of the ALTER TABLE and the result stored in a new column (attmissingval) in pg_attribute, and a new column (atthasmissing) is set to true. Any existing row when fetched will be supplied with the attmissingval. New rows will have the supplied value or the default and so will never need the attmissingval. Any time the table is rewritten all the atthasmissing and attmissingval settings for the attributes are cleared, as they are no longer needed. The most visible code change from this is in heap_attisnull, which acquires a third TupleDesc argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley. Discussion: https://postgr.es/m/31e2e921-7002-4c27-59f5-51f08404c858@2ndQuadrant.com
2018-03-28 02:13:52 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
More minor updates and copy-editing.
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
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<structfield>attlen</structfield> and the other fields copied from
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
to cope with the situation where the dropped column's data type was
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
later dropped, and so there is no <structname>pg_type</structname> row anymore.
More minor updates and copy-editing.
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>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="user-manag"/> contains detailed information about user and
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_authid</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
Add a role property 'rolinherit' which, when false, denotes that the role doesn't automatically inherit the privileges of roles it is a member of; for such a role, membership in another role can be exploited only by doing explicit SET ROLE. The default inherit setting is TRUE, so by default the behavior doesn't change, but creating a user with NOINHERIT gives closer adherence to our current reading of SQL99. Documentation still lacking, and I think the information schema needs another look.
2005-07-26 18:38:29 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a role property 'rolinherit' which, when false, denotes that the role doesn't automatically inherit the privileges of roles it is a member of; for such a role, membership in another role can be exploited only by doing explicit SET ROLE. The default inherit setting is TRUE, so by default the behavior doesn't change, but creating a user with NOINHERIT gives closer adherence to our current reading of SQL99. Documentation still lacking, and I think the information schema needs another look.
2005-07-26 18:38:29 +02:00
</row>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Misc documentation fixes. - Misc grammar and punctuation fixes. - Stylistic cleanup: use spaces between function arguments and JSON fields in examples. For example "foo(a,b)" -> "foo(a, b)". Add semicolon after last END in a few PL/pgSQL examples that were missing them. - Make sentence that talked about "..." and ".." operators more clear, by avoiding to end the sentence with "..". That makes it look the same as "..." - Fix syntax description for HAVING: HAVING conditions cannot be repeated Patch by Justin Pryzby, per Yaroslav Schekin's report. Backpatch to all supported versions, to the extent that the patch applies easily. Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com
2020-10-19 18:28:54 +02:00
session authorization identifier.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
Add REPLICATION privilege for ROLEs This privilege is required to do Streaming Replication, instead of superuser, making it possible to set up a SR slave that doesn't have write permissions on the master. Superuser privileges do NOT override this check, so in order to use the default superuser account for replication it must be explicitly granted the REPLICATION permissions. This is backwards incompatible change, in the interest of higher default security.
2010-12-29 11:05:03 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Update description of rolreplication column Since PostgreSQL 9.6, rolreplication no longer determines whether a role can run pg_start_backup() and pg_stop_backup(), so remove that. Add that this attribute determines whether a role can create and drop replication slots. Reported-by: Fujii Masao <masao.fujii@gmail.com>
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add REPLICATION privilege for ROLEs This privilege is required to do Streaming Replication, instead of superuser, making it possible to set up a SR slave that doesn't have write permissions on the master. Superuser privileges do NOT override this check, so in order to use the default superuser account for replication it must be explicitly granted the REPLICATION permissions. This is backwards incompatible change, in the interest of higher default security.
2010-12-29 11:05:03 +01:00
</row>
Add usebypassrls to pg_user and pg_shadow The row level security patches didn't add the 'usebypassrls' columns to the pg_user and pg_shadow views on the belief that they were deprecated, but we havn't actually said they are and therefore we should include it. This patch corrects that, adds missing documentation for rolbypassrls into the system catalog page for pg_authid, along with the entries for pg_user and pg_shadow, and cleans up a few other uses of 'row-level' cases to be 'row level' in the docs. Pointed out by Amit Kapila. Catalog version bump due to system view changes.
2015-01-29 03:47:15 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Improve hyphenation consistency
2021-04-21 08:14:43 +02:00
Role bypasses every row-level security policy, see
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="ddl-rowsecurity"/> for more information.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add usebypassrls to pg_user and pg_shadow The row level security patches didn't add the 'usebypassrls' columns to the pg_user and pg_shadow views on the belief that they were deprecated, but we havn't actually said they are and therefore we should include it. This patch corrects that, adds missing documentation for rolbypassrls into the system catalog page for pg_authid, along with the entries for pg_user and pg_shadow, and cleans up a few other uses of 'row-level' cases to be 'row level' in the docs. Pointed out by Amit Kapila. Catalog version bump due to system view changes.
2015-01-29 03:47:15 +01:00
</row>
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Revert "Use a bitmask to represent role attributes" This reverts commit 1826987a46d079458007b7b6bbcbbd852353adbb. The overall design was deemed unacceptable, in discussion following the previous commit message; we might find some parts of it still salvageable, but I don't want to be on the hook for fixing it, so let's wait until we have a new patch.
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
</row>
Revert "Use a bitmask to represent role attributes" This reverts commit 1826987a46d079458007b7b6bbcbbd852353adbb. The overall design was deemed unacceptable, in discussion following the previous commit message; we might find some parts of it still salvageable, but I don't want to be on the hook for fixing it, so let's wait until we have a new patch.
2014-12-23 19:35:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Revert "Use a bitmask to represent role attributes" This reverts commit 1826987a46d079458007b7b6bbcbbd852353adbb. The overall design was deemed unacceptable, in discussion following the previous commit message; we might find some parts of it still salvageable, but I don't want to be on the hook for fixing it, so let's wait until we have a new patch.
2014-12-23 19:35:49 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Revert "Use a bitmask to represent role attributes" This reverts commit 1826987a46d079458007b7b6bbcbbd852353adbb. The overall design was deemed unacceptable, in discussion following the previous commit message; we might find some parts of it still salvageable, but I don't want to be on the hook for fixing it, so let's wait until we have a new patch.
2014-12-23 19:35:49 +01:00
</row>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>.
Change the on-disk format of SCRAM verifiers to conform to RFC 5803. It doesn't make any immediate difference to PostgreSQL, but might as well follow the standard, since one exists. (I looked at RFC 5803 earlier, but didn't fully understand it back then.) The new format uses Base64 instead of hex to encode StoredKey and ServerKey, which makes the verifiers slightly smaller. Using the same encoding for the salt and the keys also means that you only need one encoder/decoder instead of two. Although we have code in the backend to do both, we are talking about teaching libpq how to create SCRAM verifiers for PQencodePassword(), and libpq doesn't currently have any code for hex encoding. Bump catversion, because this renders any existing SCRAM verifiers in pg_authid invalid. Discussion: https://www.postgresql.org/message-id/351ba574-85ea-d9b8-9689-8c928dd0955d@iki.fi
2017-04-21 21:51:57 +02:00
</para>
<para>
If the password is encrypted with SCRAM-SHA-256, it has the format:
<synopsis>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
SCRAM-SHA-256$<replaceable>&lt;iteration count&gt;</replaceable>:<replaceable>&lt;salt&gt;</replaceable>$<replaceable>&lt;StoredKey&gt;</replaceable>:<replaceable>&lt;ServerKey&gt;</replaceable>
Change the on-disk format of SCRAM verifiers to conform to RFC 5803. It doesn't make any immediate difference to PostgreSQL, but might as well follow the standard, since one exists. (I looked at RFC 5803 earlier, but didn't fully understand it back then.) The new format uses Base64 instead of hex to encode StoredKey and ServerKey, which makes the verifiers slightly smaller. Using the same encoding for the salt and the keys also means that you only need one encoder/decoder instead of two. Although we have code in the backend to do both, we are talking about teaching libpq how to create SCRAM verifiers for PQencodePassword(), and libpq doesn't currently have any code for hex encoding. Bump catversion, because this renders any existing SCRAM verifiers in pg_authid invalid. Discussion: https://www.postgresql.org/message-id/351ba574-85ea-d9b8-9689-8c928dd0955d@iki.fi
2017-04-21 21:51:57 +02:00
</synopsis>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
docs: ulink all references to RFC's Make sure that the first mentions of RFC's are ulinked to their ietf.org entry, and subsequent ones are marked as acronyms. This makes references to RFC's consistent across the documentation. Author: Daniel Gustafsson Discussion: https://www.postgresql.org/message-id/2C697878-4D01-4F06-8312-2FEDE931E973%40yesql.se
2020-12-01 13:36:30 +01:00
the same as that specified by <ulink url="https://tools.ietf.org/html/rfc5803">RFC 5803</ulink>.
Change the on-disk format of SCRAM verifiers to conform to RFC 5803. It doesn't make any immediate difference to PostgreSQL, but might as well follow the standard, since one exists. (I looked at RFC 5803 earlier, but didn't fully understand it back then.) The new format uses Base64 instead of hex to encode StoredKey and ServerKey, which makes the verifiers slightly smaller. Using the same encoding for the salt and the keys also means that you only need one encoder/decoder instead of two. Although we have code in the backend to do both, we are talking about teaching libpq how to create SCRAM verifiers for PQencodePassword(), and libpq doesn't currently have any code for hex encoding. Bump catversion, because this renders any existing SCRAM verifiers in pg_authid invalid. Discussion: https://www.postgresql.org/message-id/351ba574-85ea-d9b8-9689-8c928dd0955d@iki.fi
2017-04-21 21:51:57 +02:00
</para>
<para>
A password that does not follow either of those formats is assumed to be
unencrypted.
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677). This introduces a new generic SASL authentication method, similar to the GSS and SSPI methods. The server first tells the client which SASL authentication mechanism to use, and then the mechanism-specific SASL messages are exchanged in AuthenticationSASLcontinue and PasswordMessage messages. Only SCRAM-SHA-256 is supported at the moment, but this allows adding more SASL mechanisms in the future, without changing the overall protocol. Support for channel binding, aka SCRAM-SHA-256-PLUS is left for later. The SASLPrep algorithm, for pre-processing the password, is not yet implemented. That could cause trouble, if you use a password with non-ASCII characters, and a client library that does implement SASLprep. That will hopefully be added later. Authorization identities, as specified in the SCRAM-SHA-256 specification, are ignored. SET SESSION AUTHORIZATION provides more or less the same functionality, anyway. If a user doesn't exist, perform a "mock" authentication, by constructing an authentic-looking challenge on the fly. The challenge is derived from a new system-wide random value, "mock authentication nonce", which is created at initdb, and stored in the control file. We go through these motions, in order to not give away the information on whether the user exists, to unauthenticated users. Bumps PG_CONTROL_VERSION, because of the new field in control file. Patch by Michael Paquier and Heikki Linnakangas, reviewed at different stages by Robert Haas, Stephen Frost, David Steele, Aleksander Alekseev, and many others. Discussion: https://www.postgresql.org/message-id/CAB7nPqRbR3GmFYdedCAhzukfKrgBLTLtMvENOmPrVWREsZkF8g%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/CAB7nPqSMXU35g%3DW9X74HVeQp0uvgJxvYOuA4A-A3M%2B0wfEBv-w%40mail.gmail.com Discussion: https://www.postgresql.org/message-id/55192AFE.6080106@iki.fi
2017-03-07 13:25:40 +01:00
</para>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_auth_members</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Ensure that pg_auth_members.grantor is always valid. Previously, "GRANT foo TO bar" or "GRANT foo TO bar GRANTED BY baz" would record the OID of the grantor in pg_auth_members.grantor, but that role could later be dropped without modifying or removing the pg_auth_members record. That's not great, because we typically try to avoid dangling references in catalog data. Now, a role grant depends on the grantor, and the grantor can't be dropped without removing the grant or changing the grantor. "DROP OWNED BY" will remove the grant, just as it does for other kinds of privileges. "REASSIGN OWNED BY" will not, again just like what we do in other cases involving privileges. pg_auth_members now has an OID column, because that is needed in order for dependencies to work. It also now has an index on the grantor column, because otherwise dropping a role would require a sequential scan of the entire table to see whether the role's OID is in use as a grantor. That probably wouldn't be too large a problem in practice, but it seems better to have an index just in case. A follow-on patch is planned with the goal of more thoroughly rationalizing the behavior of role grants. This patch is just trying to do enough to make sure that the data we store in the catalogs is at some basic level valid. Patch by me, reviewed by Stephen Frost Discussion: http://postgr.es/m/CA+TgmoaFr-RZeQ+WoQ5nKPv97oT9+aDgK_a5+qWHSgbDsMp1Vg@mail.gmail.com
2022-08-18 19:13:02 +02:00
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<structfield>roleid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.<structfield>oid</structfield>)
</para>
<para>
ID of a role that has a member
</para></entry>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</row>
Allow grant-level control of role inheritance behavior. The GRANT statement can now specify WITH INHERIT TRUE or WITH INHERIT FALSE to control whether the member inherits the granted role's permissions. For symmetry, you can now likewise write WITH ADMIN TRUE or WITH ADMIN FALSE to turn ADMIN OPTION on or off. If a GRANT does not specify WITH INHERIT, the behavior based on whether the member role is marked INHERIT or NOINHERIT. This means that if all roles are marked INHERIT or NOINHERIT before any role grants are performed, the behavior is identical to what we had before; otherwise, it's different, because ALTER ROLE [NO]INHERIT now only changes the default behavior of future grants, and has no effect on existing ones. Patch by me. Reviewed and testing by Nathan Bossart and Tushar Ahuja, with design-level comments from various others. Discussion: http://postgr.es/m/CA+Tgmoa5Sf4PiWrfxA=sGzDKg0Ojo3dADw=wAHOhR9dggV=RmQ@mail.gmail.com
2022-08-25 16:06:02 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inherit_option</structfield> <type>bool</type>
</para>
<para>
True if the member automatically inherits the privileges of the
granted role
</para></entry>
</row>
Add a SET option to the GRANT command. Similar to how the INHERIT option controls whether or not the permissions of the granted role are automatically available to the grantee, the new SET permission controls whether or not the grantee may use the SET ROLE command to assume the privileges of the granted role. In addition, the new SET permission controls whether or not it is possible to transfer ownership of objects to the target role or to create new objects owned by the target role using commands such as CREATE DATABASE .. OWNER. We could alternatively have made this controlled by the INHERIT option, or allow it when either option is given. An advantage of this approach is that if you are granted a predefined role with INHERIT TRUE, SET FALSE, you can't go and create objects owned by that role. The underlying theory here is that the ability to create objects as a target role is not a privilege per se, and thus does not depend on whether you inherit the target role's privileges. However, it's surely something you could do anyway if you could SET ROLE to the target role, and thus making it contingent on whether you have that ability is reasonable. Design review by Nathan Bossat, Wolfgang Walther, Jeff Davis, Peter Eisentraut, and Stephen Frost. Discussion: http://postgr.es/m/CA+Tgmob+zDSRS6JXYrgq0NWdzCXuTNzT5eK54Dn2hhgt17nm8A@mail.gmail.com
2022-11-18 18:32:50 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>set_option</structfield> <type>bool</type>
</para>
<para>
True if the member can
<link linkend="sql-set-role"><command>SET ROLE</command></link>
to the granted role
</para></entry>
</row>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
</tbody>
</tgroup>
</table>
</sect1>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<sect1 id="catalog-pg-cast">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_cast</structname></title>
<indexterm zone="catalog-pg-cast">
<primary>pg_cast</primary>
</indexterm>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<para>
Downgrade implicit casts to text to be assignment-only, except for the ones from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
2007-06-05 23:31:09 +02:00
The catalog <structname>pg_cast</structname> stores data type conversion
Tweak documentation wording to avoid "pdfendlink" failure. HEAD documentation was failing to build as US PDF for me, because a link to "CREATE CAST" was getting split across pages. Adjust wording to remove this rather gratuitous cross-reference.
2012-05-11 00:02:37 +02:00
paths, both built-in and user-defined.
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</para>
Downgrade implicit casts to text to be assignment-only, except for the ones from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
string types, are not explicitly represented in
<structname>pg_cast</structname>.
Downgrade implicit casts to text to be assignment-only, except for the ones from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
2007-06-05 23:31:09 +02:00
</para>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_cast</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
stored if the cast method doesn't require a function.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>i</literal> means implicitly in expressions, as well as the
Spell and markup checking
2010-08-17 06:37:21 +02:00
other cases.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
Indicates how the cast is performed.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
</row>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</tbody>
</tgroup>
</table>
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
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,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
if present, must be type <type>integer</type>; it receives the type
remove tags.
2011-02-07 00:32:27 +01:00
modifier associated with the destination type, or -1
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
2004-06-16 03:27:00 +02:00
if there is none. The third argument,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<quote>length coercion functions</quote> that coerce values of the type
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
to be legal for a particular type modifier value.
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
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
Spell checker run
2004-12-13 19:05:10 +01:00
convert between data types and a second to apply the modifier.
Represent type-specific length coercion functions as pg_cast entries, eliminating the former hard-wired convention about their names. Allow pg_cast entries to represent both type coercion and length coercion in a single step --- this is represented by a function that takes an extra typmod argument, just like a length coercion function. This nicely merges the type and length coercion mechanisms into something at least a little cleaner than we had before. Make use of the single- coercion-step behavior to fix integer-to-bit coercion so that coercing to bit(n) yields the rightmost n bits of the integer instead of the leftmost n bits. This should fix recurrent complaints about the odd behavior of this coercion. Clean up the documentation of the bit string functions, and try to put it where people might actually find it. Also, get rid of the unreliable heuristics in ruleutils.c about whether to display nested coercion steps; instead require parse_coerce.c to label them properly in the first place.
2004-06-16 03:27:00 +02:00
</para>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-class">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_class</structname></title>
<indexterm zone="catalog-pg-class">
<primary>pg_class</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Doc: copy-edit the introductory para for the pg_class catalog. The previous wording had a faint archaic whiff to it, and more importantly used "catalogs" as a verb, which while cutely self-referential seems likely to provoke confusion in this particular context. Also consistently use "kind" not "type" to refer to the different kinds of relations distinguished by relkind. Per gripe from Martin Nash. Back-patch to supported versions. Discussion: https://postgr.es/m/169518739902.3727338.4793815593763320945@wrigleys.postgresql.org
2023-09-22 20:52:36 +02:00
The catalog <structname>pg_class</structname> describes tables and
other objects that have columns or are otherwise similar to a
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: copy-edit the introductory para for the pg_class catalog. The previous wording had a faint archaic whiff to it, and more importantly used "catalogs" as a verb, which while cutely self-referential seems likely to provoke confusion in this particular context. Also consistently use "kind" not "type" to refer to the different kinds of relations distinguished by relkind. Per gripe from Martin Nash. Back-patch to supported versions. Discussion: https://postgr.es/m/169518739902.3727338.4793815593763320945@wrigleys.postgresql.org
2023-09-22 20:52:36 +02:00
<quote>relations</quote>. Not all of <structname>pg_class</structname>'s
columns are meaningful for all relation kinds.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_class</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
pg_class has a relnamespace column. You can create and access tables in schemas other than the system namespace; however, there's no search path yet, and not all operations work yet on tables outside the system namespace.
2002-03-26 20:17:02 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
pg_class has a relnamespace column. You can create and access tables in schemas other than the system namespace; however, there's no search path yet, and not all operations work yet on tables outside the system namespace.
2002-03-26 20:17:02 +01:00
The OID of the namespace that contains this relation
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
pg_class has a relnamespace column. You can create and access tables in schemas other than the system namespace; however, there's no search path yet, and not all operations work yet on tables outside the system namespace.
2002-03-26 20:17:02 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Spell checker run
2004-12-13 19:05:10 +01:00
The OID of the data type that corresponds to this table's row type,
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
if any; zero for indexes, sequences, and toast tables, which have
no <structname>pg_type</structname> entry
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Add missing description of reloftype field
2010-08-25 20:18:41 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
For typed tables, the OID of the underlying composite type;
Add missing description of reloftype field
2010-08-25 20:18:41 +02:00
zero for all other relations
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add missing description of reloftype field
2010-08-25 20:18:41 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow specifying an access method for partitioned tables It's now possible to specify a table access method via CREATE TABLE ... USING for a partitioned table, as well change it with ALTER TABLE ... SET ACCESS METHOD. Specifying an AM for a partitioned table lets the value be used for all future partitions created under it, closely mirroring the behavior of the TABLESPACE option for partitioned tables. Existing partitions are not modified. For a partitioned table with no AM specified, any new partitions are created with the default_table_access_method. Also add ALTER TABLE ... SET ACCESS METHOD DEFAULT, which reverts to the original state of using the default for new partitions. The relcache of partitioned tables is not changed: rd_tableam is not set, even if a partitioned table has a relam set. Author: Justin Pryzby <pryzby@telsasoft.com> Author: Soumyadeep Chakraborty <soumyadeep2007@gmail.com> Author: Michaël Paquier <michael@paquier.xyz> Reviewed-by: The authors themselves Discussion: https://postgr.es/m/CAE-ML+9zM4wJCGCBGv01k96qQ3gFv4WFcFy=zqPHKeaEFwwv6A@mail.gmail.com Discussion: https://postgr.es/m/20210308010707.GA29832%40telsasoft.com
2024-03-25 16:30:36 +01:00
The access method used to access this table or index.
Not meaningful if the relation is a sequence or
has no on-disk file,
except for partitioned tables, where, if set, it takes
precedence over <varname>default_table_access_method</varname>
when determining the access method to use for partitions created
when one is not specified in the creation command.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Revert 56-bit relfilenode change and follow-up commits. There are still some alignment-related failures in the buildfarm, which might or might not be able to be fixed quickly, but I've also just realized that it increased the size of many WAL records by 4 bytes because a block reference contains a RelFileLocator. The effect of that hasn't been studied or discussed, so revert for now.
2022-09-28 15:45:27 +02:00
<structfield>relfilenode</structfield> <type>oid</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Name of the on-disk file of this relation; zero means this
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
is a <quote>mapped</quote> relation whose disk file name is determined
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
by low-level state
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Review wording on tablespaces w.r.t. partitioned tables Remove a redundant comment, and document pg_class.reltablespace properly in catalogs.sgml. After commits a36c84c3e4a9, 87259588d0ab and others. Backpatch to 12. Discussion: https://postgr.es/m/202403191013.w2kr7wqlamqz@alvherre.pgsql
2024-03-20 15:28:14 +01:00
The tablespace in which this relation is stored.
If zero, the database's default tablespace is implied.
Not meaningful if the relation has no on-disk file,
except for partitioned tables, where this is the tablespace
in which partitions will be created when one is not
specified in the creation command.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Change planner to use the current true disk file size as its estimate of a relation's number of blocks, rather than the possibly-obsolete value in pg_class.relpages. Scale the value in pg_class.reltuples correspondingly to arrive at a hopefully more accurate number of rows. When pg_class contains 0/0, estimate a tuple width from the column datatypes and divide that into current file size to estimate number of rows. This improved methodology allows us to jettison the ancient hacks that put bogus default values into pg_class when a table is first created. Also, per a suggestion from Simon, make VACUUM (but not VACUUM FULL or ANALYZE) adjust the value it puts into pg_class.reltuples to try to represent the mean tuple density instead of the minimal density that actually prevails just after VACUUM. These changes alter the plans selected for certain regression tests, so update the expected files accordingly. (I removed join_1.out because it's not clear if it still applies; we can add back any variant versions as they are shown to be needed.)
2004-12-01 20:00:56 +01:00
Size of the on-disk representation of this table in pages (of size
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Sync up our various ways of estimating pg_class.reltuples. VACUUM thought that reltuples represents the total number of tuples in the relation, while ANALYZE counted only live tuples. This can cause "flapping" in the value when background vacuums and analyzes happen separately. The planner's use of reltuples essentially assumes that it's the count of live (visible) tuples, so let's standardize on having it mean live tuples. Another issue is that the definition of "live tuple" isn't totally clear; what should be done with INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples? ANALYZE's choices in this regard are made on the assumption that if the originating transaction commits at all, it will happen after ANALYZE finishes, so we should ignore the effects of the in-progress transaction --- unless it is our own transaction, and then we should count it. Let's propagate this definition into VACUUM, too. Likewise propagate this definition into CREATE INDEX, and into contrib/pgstattuple's pgstattuple_approx() function. Tomas Vondra, reviewed by Haribabu Kommi, some corrections by me Discussion: https://postgr.es/m/16db4468-edfa-830a-f921-39a50498e77e@2ndquadrant.com
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Measure the number of all-visible pages for use in index-only scan costing. Add a column pg_class.relallvisible to remember the number of pages that were all-visible according to the visibility map as of the last VACUUM (or ANALYZE, or some other operations that update pg_class.relpages). Use relallvisible/relpages, instead of an arbitrary constant, to estimate how many heap page fetches can be avoided during an index-only scan. This is pretty primitive and will no doubt see refinements once we've acquired more field experience with the index-only scan mechanism, but it's way better than using a constant. Note: I had to adjust an underspecified query in the window.sql regression test, because it was changing answers when the plan changed to use an index-only scan. Some of the adjacent tests perhaps should be adjusted as well, but I didn't do that here.
2011-10-14 23:23:01 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Measure the number of all-visible pages for use in index-only scan costing. Add a column pg_class.relallvisible to remember the number of pages that were all-visible according to the visibility map as of the last VACUUM (or ANALYZE, or some other operations that update pg_class.relpages). Use relallvisible/relpages, instead of an arbitrary constant, to estimate how many heap page fetches can be avoided during an index-only scan. This is pretty primitive and will no doubt see refinements once we've acquired more field experience with the index-only scan mechanism, but it's way better than using a constant. Note: I had to adjust an underspecified query in the window.sql regression test, because it was changing answers when the plan changed to use an index-only scan. Some of the adjacent tests perhaps should be adjusted as well, but I didn't do that here.
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>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Measure the number of all-visible pages for use in index-only scan costing. Add a column pg_class.relallvisible to remember the number of pages that were all-visible according to the visibility map as of the last VACUUM (or ANALYZE, or some other operations that update pg_class.relpages). Use relallvisible/relpages, instead of an arbitrary constant, to estimate how many heap page fetches can be avoided during an index-only scan. This is pretty primitive and will no doubt see refinements once we've acquired more field experience with the index-only scan mechanism, but it's way better than using a constant. Note: I had to adjust an underspecified query in the window.sql regression test, because it was changing answers when the plan changed to use an index-only scan. Some of the adjacent tests perhaps should be adjusted as well, but I didn't do that here.
2011-10-14 23:23:01 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
OID of the TOAST table associated with this table, zero if none. The
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
TOAST table stores large attributes <quote>out of line</quote> in a
Spell and markup checking
2010-08-17 06:37:21 +02:00
secondary table.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
True if this is a table and it has (or recently had) any indexes
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
True if this table is shared across all databases in the cluster. Only
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
certain system catalogs (such as <link linkend="catalog-pg-database"><structname>pg_database</structname></link>)
Spell and markup checking
2010-08-17 06:37:21 +02:00
are shared.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Add a "relistemp" boolean column to pg_class, which is true for temporary relations (including a temp table's indexes and toast table/index), and false for normal relations. For ease of checking, this commit just adds the column and fills it correctly --- revising the relation access machinery to use it will come separately.
2009-03-31 19:59:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Docs: Mention that relpersistence is for sequences now too Per 344d62fb9. Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
2022-04-11 10:50:20 +02:00
<literal>p</literal> = permanent table/sequence, <literal>u</literal> = unlogged table/sequence,
<literal>t</literal> = temporary table/sequence
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add a "relistemp" boolean column to pg_class, which is true for temporary relations (including a temp table's indexes and toast table/index), and false for normal relations. For ease of checking, this commit just adds the column and fills it correctly --- revising the relation access machinery to use it will come separately.
2009-03-31 19:59:56 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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,
Add relkind 'I' to catalog.sgml's list relkinds Commit 8b08f7d4820f added a relkind for local partitioned indexes, but failed to add it to pg_class's list of possible relkinds. Repair. Author: Peter Geoghegan, Michaël Paquier Discussion: https://postgr.es/m/CAH2-WzkOKptQiE51Bh4_xeEHhaBwHkZkGtKizrFMgEkfUuRRQg@mail.gmail.com
2018-05-09 18:32:50 +02:00
<literal>p</literal> = partitioned table,
<literal>I</literal> = partitioned index
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Number of <literal>CHECK</literal> constraints on the table; see
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
<link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> catalog
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
True if table has (or once had) rules; see
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
<link linkend="catalog-pg-rewrite"><structname>pg_rewrite</structname></link> catalog
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
2008-11-09 22:24:33 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Replace pg_class.reltriggers with relhastriggers, which is just a boolean hint ("there might be triggers") rather than an exact count. This is necessary catalog infrastructure for the upcoming patch to reduce the strength of locking needed for trigger addition/removal. Split out and committed separately for ease of reviewing/testing. In passing, also get rid of the unused pg_class columns relukeys, relfkeys, and relrefs, which haven't been maintained in many years and now have no chance of ever being maintained (because of wishing to avoid locking). Simon Riggs
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: avoid saying "inheritance" ... ... when it applies to partitioned relations. This is almost the opposite of 0c06534bd63b, which removed references to "partition" in favour of "child". Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/20220525013248.GO19626@telsasoft.com
2022-07-28 18:21:56 +02:00
True if table or index has (or once had) any inheritance children or partitions
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Improve hyphenation consistency
2021-04-21 08:14:43 +02:00
True if table has row-level security enabled; see
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
<link linkend="catalog-pg-policy"><structname>pg_policy</structname></link> catalog
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
ALTER TABLE .. FORCE ROW LEVEL SECURITY To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS context to avoid data corruption when ALTER TABLE .. FORCE ROW SECURITY is being used. The SECURITY_NOFORCE_RLS security context is used only during referential integrity checks and is only considered in check_enable_rls() after we have already checked that the current user is the owner of the relation (which should always be the case during referential integrity checks). Back-patch to 9.5 where RLS was added.
2015-10-05 03:05:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Improve hyphenation consistency
2021-04-21 08:14:43 +02:00
True if row-level security (when enabled) will also apply to table owner; see
ALTER TABLE .. FORCE ROW LEVEL SECURITY To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS context to avoid data corruption when ALTER TABLE .. FORCE ROW SECURITY is being used. The SECURITY_NOFORCE_RLS security context is used only during referential integrity checks and is only considered in check_enable_rls() after we have already checked that the current user is the owner of the relation (which should always be the case during referential integrity checks). Back-patch to 9.5 where RLS was added.
2015-10-05 03:05:08 +02:00
<link linkend="catalog-pg-policy"><structname>pg_policy</structname></link> catalog
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
ALTER TABLE .. FORCE ROW LEVEL SECURITY To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS context to avoid data corruption when ALTER TABLE .. FORCE ROW SECURITY is being used. The SECURITY_NOFORCE_RLS security context is used only during referential integrity checks and is only considered in check_enable_rls() after we have already checked that the current user is the owner of the relation (which should always be the case during referential integrity checks). Back-patch to 9.5 where RLS was added.
2015-10-05 03:05:08 +02:00
</row>
Move materialized views' is-populated status into their pg_class entries. Previously this state was represented by whether the view's disk file had zero or nonzero size, which is problematic for numerous reasons, since it's breaking a fundamental assumption about heap storage. This was done to allow unlogged matviews to revert to unpopulated status after a crash despite our lack of any ability to update catalog entries post-crash. However, this poses enough risk of future problems that it seems better to not support unlogged matviews until we can find another way. Accordingly, revert that choice as well as a number of existing kluges forced by it in favor of creating a pg_class.relispopulated flag column.
2013-05-06 19:26:51 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Move materialized views' is-populated status into their pg_class entries. Previously this state was represented by whether the view's disk file had zero or nonzero size, which is problematic for numerous reasons, since it's breaking a fundamental assumption about heap storage. This was done to allow unlogged matviews to revert to unpopulated status after a crash despite our lack of any ability to update catalog entries post-crash. However, this poses enough risk of future problems that it seems better to not support unlogged matviews until we can find another way. Accordingly, revert that choice as well as a number of existing kluges forced by it in favor of creating a pg_class.relispopulated flag column.
2013-05-06 19:26:51 +02:00
</row>
Add the notion of REPLICA IDENTITY for a table. Pending patches for logical replication will use this to determine which columns of a tuple ought to be considered as its candidate key. Andres Freund, with minor, mostly cosmetic adjustments by me
2013-11-08 18:30:43 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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,
Doc: Fix description of pg_class.relreplident The description missed a comma and lacked an explanation of what happens with REPLICA IDENTITY USING INDEX when the dependent index is dropped. Author: Marina Polyakova Reviewed-by: Daniel Gustafsson, Michael Paquier Discussion: https://postgr.es/m/ad1a0badc32658b1bbb07aa312346a1d@postgrespro.ru Backpatch-through: 9.5
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)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add the notion of REPLICA IDENTITY for a table. Pending patches for logical replication will use this to determine which columns of a tuple ought to be considered as its candidate key. Andres Freund, with minor, mostly cosmetic adjustments by me
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Handle heap rewrites even better in logical decoding Logical decoding should not publish anything about tables created as part of a heap rewrite during DDL. Those tables don't exist externally, so consumers of logical decoding cannot do anything sensible with that information. In ab28feae2bd3d4629bd73ae3548e671c57d785f0, we worked around this for built-in logical replication, but that was hack. This is a more proper fix: We mark such transient heaps using the new field pg_class.relwrite, linking to the original relation OID. By default, we ignore them in logical decoding before they get to the output plugin. Optionally, a plugin can register their interest in getting such changes, if they handle DDL specially, in which case the new field will help them get information about the actual table. Reviewed-by: Craig Ringer <craig@2ndquadrant.com>
2018-03-21 14:13:24 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Handle heap rewrites even better in logical decoding Logical decoding should not publish anything about tables created as part of a heap rewrite during DDL. Those tables don't exist externally, so consumers of logical decoding cannot do anything sensible with that information. In ab28feae2bd3d4629bd73ae3548e671c57d785f0, we worked around this for built-in logical replication, but that was hack. This is a more proper fix: We mark such transient heaps using the new field pg_class.relwrite, linking to the original relation OID. By default, we ignore them in logical decoding before they get to the output plugin. Optionally, a plugin can register their interest in getting such changes, if they handle DDL specially, in which case the new field will help them get information about the actual table. Reviewed-by: Craig Ringer <craig@2ndquadrant.com>
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;
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
otherwise zero. That state is only visible internally; this field should
never contain anything other than zero for a user-visible relation.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Handle heap rewrites even better in logical decoding Logical decoding should not publish anything about tables created as part of a heap rewrite during DDL. Those tables don't exist externally, so consumers of logical decoding cannot do anything sensible with that information. In ab28feae2bd3d4629bd73ae3548e671c57d785f0, we worked around this for built-in logical replication, but that was hack. This is a more proper fix: We mark such transient heaps using the new field pg_class.relwrite, linking to the original relation OID. By default, we ignore them in logical decoding before they get to the output plugin. Optionally, a plugin can register their interest in getting such changes, if they handle DDL specially, in which case the new field will help them get information about the actual table. Reviewed-by: Craig Ringer <craig@2ndquadrant.com>
2018-03-21 14:13:24 +01:00
</row>
Improve vacuum code to track minimum Xids per table instead of per database. To this end, add a couple of columns to pg_class, relminxid and relvacuumxid, based on which we calculate the pg_database columns after each vacuum. We now force all databases to be vacuumed, even template ones. A backend noticing too old a database (meaning pg_database.datminxid is in danger of falling behind Xid wraparound) will signal the postmaster, which in turn will start an autovacuum iteration to process the offending database. In principle this is only there to cope with frozen (non-connectable) databases without forcing users to set them to connectable, but it could force regular user database to go through a database-wide vacuum at any time. Maybe we should warn users about this somehow. Of course the real solution will be to use autovacuum all the time ;-) There are some additional improvements we could have in this area: for example the vacuum code could be smarter about not updating pg_database for each table when called by autovacuum, and do it only once the whole autovacuum iteration is done. I updated the system catalogs documentation, but I didn't modify the maintenance section. Also having some regression tests for this would be nice but it's not really a very straightforward thing to do. Catalog version bumped due to system catalog changes.
2006-07-10 18:20:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
ID wraparound or to allow <literal>pg_xact</literal> to be shrunk. Zero
Spell and markup checking
2010-08-17 06:37:21 +02:00
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Improve vacuum code to track minimum Xids per table instead of per database. To this end, add a couple of columns to pg_class, relminxid and relvacuumxid, based on which we calculate the pg_database columns after each vacuum. We now force all databases to be vacuumed, even template ones. A backend noticing too old a database (meaning pg_database.datminxid is in danger of falling behind Xid wraparound) will signal the postmaster, which in turn will start an autovacuum iteration to process the offending database. In principle this is only there to cope with frozen (non-connectable) databases without forcing users to set them to connectable, but it could force regular user database to go through a database-wide vacuum at any time. Maybe we should warn users about this somehow. Of course the real solution will be to use autovacuum all the time ;-) There are some additional improvements we could have in this area: for example the vacuum code could be smarter about not updating pg_database for each table when called by autovacuum, and do it only once the whole autovacuum iteration is done. I updated the system catalogs documentation, but I didn't modify the maintenance section. Also having some regression tests for this would be nice but it's not really a very straightforward thing to do. Catalog version bumped due to system catalog changes.
2006-07-10 18:20:52 +02:00
</row>
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
2013-06-27 21:20:33 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix some issues in pg_class.relminmxid and pg_database.datminmxid documentation. - Correct the name of directory which those catalog columns allow to be shrunk. - Correct the name of symbol which is used as the value of pg_class.relminmxid when the relation is not a table. - Fix "ID ID" typo. Backpatch to 9.3 where those cataog columns were introduced.
2015-06-04 06:22:49 +02:00
All multixact IDs before this one have been replaced by a
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
2013-06-27 21:20:33 +02:00
transaction ID in this table. This is used to track
Fix some issues in pg_class.relminmxid and pg_database.datminmxid documentation. - Correct the name of directory which those catalog columns allow to be shrunk. - Correct the name of symbol which is used as the value of pg_class.relminmxid when the relation is not a table. - Fix "ID ID" typo. Backpatch to 9.3 where those cataog columns were introduced.
2015-06-04 06:22:49 +02:00
whether the table needs to be vacuumed in order to prevent multixact ID
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
wraparound or to allow <literal>pg_multixact</literal> to be shrunk. Zero
Fix some issues in pg_class.relminmxid and pg_database.datminmxid documentation. - Correct the name of directory which those catalog columns allow to be shrunk. - Correct the name of symbol which is used as the value of pg_class.relminmxid when the relation is not a table. - Fix "ID ID" typo. Backpatch to 9.3 where those cataog columns were introduced.
2015-06-04 06:22:49 +02:00
(<symbol>InvalidMultiXactId</symbol>) if the relation is not a table.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
2013-06-27 21:20:33 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Code review for FILLFACTOR patch. Change WITH grammar as per earlier discussion (including making def_arg allow reserved words), add missed opt_definition for UNIQUE case. Put the reloptions support code in a less random place (I chose to make a new file access/common/reloptions.c). Eliminate header inclusion creep. Make the index options functions safely user-callable (seems like client apps might like to be able to test validity of options before trying to make an index). Reduce overhead for normal case with no options by allowing rd_options to be NULL. Fix some unmaintainably klugy code, including getting rid of Natts_pg_class_fixed at long last. Some stylistic cleanup too, and pay attention to keeping comments in sync with code. Documentation still needs work, though I did fix the omissions in catalogs.sgml and indexam.sgml.
2006-07-04 00:45:41 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Access-method-specific options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Code review for FILLFACTOR patch. Change WITH grammar as per earlier discussion (including making def_arg allow reserved words), add missed opt_definition for UNIQUE case. Put the reloptions support code in a less random place (I chose to make a new file access/common/reloptions.c). Eliminate header inclusion creep. Make the index options functions safely user-callable (seems like client apps might like to be able to test validity of options before trying to make an index). Reduce overhead for normal case with no options by allowing rd_options to be NULL. Fix some unmaintainably klugy code, including getting rid of Natts_pg_class_fixed at long last. Some stylistic cleanup too, and pay attention to keeping comments in sync with code. Documentation still needs work, though I did fix the omissions in catalogs.sgml and indexam.sgml.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Several of the Boolean flags in <structname>pg_class</structname> are maintained
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>relhasindex</structfield> if it finds the table has no indexes. This
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
arrangement avoids race conditions and improves concurrency.
</para>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
<sect1 id="catalog-pg-collation">
<title><structname>pg_collation</structname></title>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
<indexterm zone="catalog-pg-collation">
<primary>pg_collation</primary>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</indexterm>
<para>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
See <xref linkend="collation"/> for more information.
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_collation</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
The OID of the namespace that contains this collation
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
ICU support Add a column collprovider to pg_collation that determines which library provides the collation data. The existing choices are default and libc, and this adds an icu choice, which uses the ICU4C library. The pg_locale_t type is changed to a union that contains the provider-specific locale handles. Users of locale information are changed to look into that struct for the appropriate handle to use. Also add a collversion column that records the version of the collation when it is created, and check at run time whether it is still the same. This detects potentially incompatible library upgrades that can corrupt indexes and other structures. This is currently only supported by ICU-provided collations. initdb initializes the default collation set as before from the `locale -a` output but also adds all available ICU locales with a "-x-icu" appended. Currently, ICU-provided collations can only be explicitly named collations. The global database locales are still always libc-provided. ICU support is enabled by configure --with-icu. Reviewed-by: Thomas Munro <thomas.munro@enterprisedb.com> Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2017-03-23 20:25:34 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
ICU support Add a column collprovider to pg_collation that determines which library provides the collation data. The existing choices are default and libc, and this adds an icu choice, which uses the ICU4C library. The pg_locale_t type is changed to a union that contains the provider-specific locale handles. Users of locale information are changed to look into that struct for the appropriate handle to use. Also add a collversion column that records the version of the collation when it is created, and check at run time whether it is still the same. This detects potentially incompatible library upgrades that can corrupt indexes and other structures. This is currently only supported by ICU-provided collations. initdb initializes the default collation set as before from the `locale -a` output but also adds all available ICU locales with a "-x-icu" appended. Currently, ICU-provided collations can only be explicitly named collations. The global database locales are still always libc-provided. ICU support is enabled by configure --with-icu. Reviewed-by: Thomas Munro <thomas.munro@enterprisedb.com> Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2017-03-23 20:25:34 +01:00
</row>
Collations with nondeterministic comparison This adds a flag "deterministic" to collations. If that is false, such a collation disables various optimizations that assume that strings are equal only if they are byte-wise equal. That then allows use cases such as case-insensitive or accent-insensitive comparisons or handling of strings with different Unicode normal forms. This functionality is only supported with the ICU provider. At least glibc doesn't appear to have any locales that work in a nondeterministic way, so it's not worth supporting this for the libc provider. The term "deterministic comparison" in this context is from Unicode Technical Standard #10 (https://unicode.org/reports/tr10/#Deterministic_Comparison). This patch makes changes in three areas: - CREATE COLLATION DDL changes and system catalog changes to support this new flag. - Many executor nodes and auxiliary code are extended to track collations. Previously, this code would just throw away collation information, because the eventually-called user-defined functions didn't use it since they only cared about equality, which didn't need collation information. - String data type functions that do equality comparisons and hashing are changed to take the (non-)deterministic flag into account. For comparison, this just means skipping various shortcuts and tie breakers that use byte-wise comparison. For hashing, we first need to convert the input string to a canonical "sort key" using the ICU analogue of strxfrm(). Reviewed-by: Daniel Verite <daniel@manitou-mail.org> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://www.postgresql.org/message-id/flat/1ccc668f-4cbc-0bef-af67-450b47cdfee7@2ndquadrant.com
2019-03-22 12:09:32 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Collations with nondeterministic comparison This adds a flag "deterministic" to collations. If that is false, such a collation disables various optimizations that assume that strings are equal only if they are byte-wise equal. That then allows use cases such as case-insensitive or accent-insensitive comparisons or handling of strings with different Unicode normal forms. This functionality is only supported with the ICU provider. At least glibc doesn't appear to have any locales that work in a nondeterministic way, so it's not worth supporting this for the libc provider. The term "deterministic comparison" in this context is from Unicode Technical Standard #10 (https://unicode.org/reports/tr10/#Deterministic_Comparison). This patch makes changes in three areas: - CREATE COLLATION DDL changes and system catalog changes to support this new flag. - Many executor nodes and auxiliary code are extended to track collations. Previously, this code would just throw away collation information, because the eventually-called user-defined functions didn't use it since they only cared about equality, which didn't need collation information. - String data type functions that do equality comparisons and hashing are changed to take the (non-)deterministic flag into account. For comparison, this just means skipping various shortcuts and tie breakers that use byte-wise comparison. For hashing, we first need to convert the input string to a canonical "sort key" using the ICU analogue of strxfrm(). Reviewed-by: Daniel Verite <daniel@manitou-mail.org> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://www.postgresql.org/message-id/flat/1ccc668f-4cbc-0bef-af67-450b47cdfee7@2ndquadrant.com
2019-03-22 12:09:32 +01:00
</row>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Change collate and ctype fields to type text This changes the data type of the catalog fields datcollate, datctype, collcollate, and collctype from name to text. There wasn't ever a really good reason for them to be of type name; presumably this was just carried over from when they were fixed-size fields in pg_control, first into the corresponding pg_database fields, and then to pg_collation. The values are not identifiers or object names, and we don't ever look them up that way. Changing to type text saves space in the typical case, since locale names are typically only a few bytes long. But it is also possible that an ICU locale name with several customization options appended could be longer than 63 bytes, so this also enables that case, which was previously probably broken. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a@2ndquadrant.com
2022-01-27 08:44:31 +01:00
<structfield>collcollate</structfield> <type>text</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Catalog changes preparing for builtin collation provider. Rename pg_collation.colliculocale to colllocale, and pg_database.daticulocale to datlocale. These names reflects that the fields will be useful for the upcoming builtin provider as well, not just for ICU. This is purely a rename; no changes to the meaning of the fields. Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com Reviewed-by: Peter Eisentraut
2024-03-09 23:48:18 +01:00
<symbol>LC_COLLATE</symbol> for this collation object. If the provider is
not <literal>libc</literal>, <structfield>collcollate</structfield> is
<literal>NULL</literal> and <structfield>colllocale</structfield> is
used instead.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Change collate and ctype fields to type text This changes the data type of the catalog fields datcollate, datctype, collcollate, and collctype from name to text. There wasn't ever a really good reason for them to be of type name; presumably this was just carried over from when they were fixed-size fields in pg_control, first into the corresponding pg_database fields, and then to pg_collation. The values are not identifiers or object names, and we don't ever look them up that way. Changing to type text saves space in the typical case, since locale names are typically only a few bytes long. But it is also possible that an ICU locale name with several customization options appended could be longer than 63 bytes, so this also enables that case, which was previously probably broken. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a@2ndquadrant.com
2022-01-27 08:44:31 +01:00
<structfield>collctype</structfield> <type>text</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Catalog changes preparing for builtin collation provider. Rename pg_collation.colliculocale to colllocale, and pg_database.daticulocale to datlocale. These names reflects that the fields will be useful for the upcoming builtin provider as well, not just for ICU. This is purely a rename; no changes to the meaning of the fields. Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com Reviewed-by: Peter Eisentraut
2024-03-09 23:48:18 +01:00
<symbol>LC_CTYPE</symbol> for this collation object. If the provider is
not <literal>libc</literal>, <structfield>collctype</structfield> is
<literal>NULL</literal> and <structfield>colllocale</structfield> is
used instead.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</row>
Revert per-index collation version tracking feature. Design problems were discovered in the handling of composite types and record types that would cause some relevant versions not to be recorded. Misgivings were also expressed about the use of the pg_depend catalog for this purpose. We're out of time for this release so we'll revert and try again. Commits reverted: 1bf946bd: Doc: Document known problem with Windows collation versions. cf002008: Remove no-longer-relevant test case. ef387bed: Fix bogus collation-version-recording logic. 0fb0a050: Hide internal error for pg_collation_actual_version(<bad OID>). ff942057: Suppress "warning: variable 'collcollate' set but not used". d50e3b1f: Fix assertion in collation version lookup. f24b1569: Rethink extraction of collation dependencies. 257836a7: Track collation versions for indexes. cd6f479e: Add pg_depend.refobjversion. 7d1297df: Remove pg_collation.collversion. Discussion: https://postgr.es/m/CA%2BhUKGLhj5t1fcjqAu8iD9B3ixJtsTNqyCCD4V0aTO9kAKAjjA%40mail.gmail.com
2021-05-07 10:17:42 +02:00
Add option to use ICU as global locale provider This adds the option to use ICU as the default locale provider for either the whole cluster or a database. New options for initdb, createdb, and CREATE DATABASE are used to select this. Since some (legacy) code still uses the libc locale facilities directly, we still need to set the libc global locale settings even if ICU is otherwise selected. So pg_database now has three locale-related fields: the existing datcollate and datctype, which are always set, and a new daticulocale, which is only set if ICU is selected. A similar change is made in pg_collation for consistency, but in that case, only the libc-related fields or the ICU-related field is set, never both. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com
2022-03-17 11:11:21 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Catalog changes preparing for builtin collation provider. Rename pg_collation.colliculocale to colllocale, and pg_database.daticulocale to datlocale. These names reflects that the fields will be useful for the upcoming builtin provider as well, not just for ICU. This is purely a rename; no changes to the meaning of the fields. Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com Reviewed-by: Peter Eisentraut
2024-03-09 23:48:18 +01:00
<structfield>colllocale</structfield> <type>text</type>
Add option to use ICU as global locale provider This adds the option to use ICU as the default locale provider for either the whole cluster or a database. New options for initdb, createdb, and CREATE DATABASE are used to select this. Since some (legacy) code still uses the libc locale facilities directly, we still need to set the libc global locale settings even if ICU is otherwise selected. So pg_database now has three locale-related fields: the existing datcollate and datctype, which are always set, and a new daticulocale, which is only set if ICU is selected. A similar change is made in pg_collation for consistency, but in that case, only the libc-related fields or the ICU-related field is set, never both. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com
2022-03-17 11:11:21 +01:00
</para>
<para>
Catalog changes preparing for builtin collation provider. Rename pg_collation.colliculocale to colllocale, and pg_database.daticulocale to datlocale. These names reflects that the fields will be useful for the upcoming builtin provider as well, not just for ICU. This is purely a rename; no changes to the meaning of the fields. Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com Reviewed-by: Peter Eisentraut
2024-03-09 23:48:18 +01:00
Collation provider locale name for this collation object. If the
provider is <literal>libc</literal>,
<structfield>colllocale</structfield> is <literal>NULL</literal>;
<structfield>collcollate</structfield> and
<structfield>collctype</structfield> are used instead.
Add option to use ICU as global locale provider This adds the option to use ICU as the default locale provider for either the whole cluster or a database. New options for initdb, createdb, and CREATE DATABASE are used to select this. Since some (legacy) code still uses the libc locale facilities directly, we still need to set the libc global locale settings even if ICU is otherwise selected. So pg_database now has three locale-related fields: the existing datcollate and datctype, which are always set, and a new daticulocale, which is only set if ICU is selected. A similar change is made in pg_collation for consistency, but in that case, only the libc-related fields or the ICU-related field is set, never both. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com
2022-03-17 11:11:21 +01:00
</para></entry>
</row>
Allow tailoring of ICU locales with custom rules This exposes the ICU facility to add custom collation rules to a standard collation. New options are added to CREATE COLLATION, CREATE DATABASE, createdb, and initdb to set the rules. Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: Daniel Verite <daniel@manitou-mail.org> Discussion: https://www.postgresql.org/message-id/flat/821c71a4-6ef0-d366-9acf-bb8e367f739f@enterprisedb.com
2023-03-08 16:35:42 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collicurules</structfield> <type>text</type>
</para>
<para>
ICU collation rules for this collation object
</para></entry>
</row>
Revert per-index collation version tracking feature. Design problems were discovered in the handling of composite types and record types that would cause some relevant versions not to be recorded. Misgivings were also expressed about the use of the pg_depend catalog for this purpose. We're out of time for this release so we'll revert and try again. Commits reverted: 1bf946bd: Doc: Document known problem with Windows collation versions. cf002008: Remove no-longer-relevant test case. ef387bed: Fix bogus collation-version-recording logic. 0fb0a050: Hide internal error for pg_collation_actual_version(<bad OID>). ff942057: Suppress "warning: variable 'collcollate' set but not used". d50e3b1f: Fix assertion in collation version lookup. f24b1569: Rethink extraction of collation dependencies. 257836a7: Track collation versions for indexes. cd6f479e: Add pg_depend.refobjversion. 7d1297df: Remove pg_collation.collversion. Discussion: https://postgr.es/m/CA%2BhUKGLhj5t1fcjqAu8iD9B3ixJtsTNqyCCD4V0aTO9kAKAjjA%40mail.gmail.com
2021-05-07 10:17:42 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>collversion</structfield> <type>text</type>
</para>
<para>
Provider-specific version of the collation. This is recorded when the
collation is created and then checked when it is used, to detect
changes in the collation definition that could lead to data corruption.
</para></entry>
</row>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</tbody>
</tgroup>
</table>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>).
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
<productname>PostgreSQL</productname> generally ignores all
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
collations that do not have <structfield>collencoding</structfield> equal to
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
either the current database's encoding or -1, and creation of new entries
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
with the same name as an entry with <structfield>collencoding</structfield> = -1
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
is forbidden. Therefore it is sufficient to use a qualified SQL name
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
(<replaceable>schema</replaceable>.<replaceable>name</replaceable>) to identify a collation,
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<application>initdb</application> fills it in at cluster initialization time with
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
In the <literal>template0</literal> database, it could be useful to create
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>template0</literal>. This would currently have to be done manually.
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</para>
Syntax support and documentation for event triggers. They don't actually do anything yet; that will get fixed in a follow-on commit. But this gets the basic infrastructure in place, including CREATE/ALTER/DROP EVENT TRIGGER; support for COMMENT, SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP EVENT TRIGGER; pg_dump and psql support; and documentation for the anticipated initial feature set. Dimitri Fontaine, with review and a bunch of additional hacking by me. Thom Brown extensively reviewed earlier versions of this patch set, but there's not a whole lot of that code left in this commit, as it turns out.
2012-07-18 16:16:16 +02:00
</sect1>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<sect1 id="catalog-pg-constraint">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_constraint</structname></title>
<indexterm zone="catalog-pg-constraint">
<primary>pg_constraint</primary>
</indexterm>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<para>
Catalog not-null constraints We now create contype='n' pg_constraint rows for not-null constraints. We propagate these constraints to other tables during operations such as adding inheritance relationships, creating and attaching partitions and creating tables LIKE other tables. We also spawn not-null constraints for inheritance child tables when their parents have primary keys. These related constraints mostly follow the well-known rules of conislocal and coninhcount that we have for CHECK constraints, with some adaptations: for example, as opposed to CHECK constraints, we don't match not-null ones by name when descending a hierarchy to alter it, instead matching by column name that they apply to. This means we don't require the constraint names to be identical across a hierarchy. For now, we omit them for system catalogs. Maybe this is worth reconsidering. We don't support NOT VALID nor DEFERRABLE clauses either; these can be added as separate features later (this patch is already large and complicated enough.) psql shows these constraints in \d+. pg_dump requires some ad-hoc hacks, particularly when dumping a primary key. We now create one "throwaway" not-null constraint for each column in the PK together with the CREATE TABLE command, and once the PK is created, all those throwaway constraints are removed. This avoids having to check each tuple for nullness when the dump restores the primary key creation. pg_upgrading from an older release requires a somewhat brittle procedure to create a constraint state that matches what would be created if the database were being created fresh in Postgres 17. I have tested all the scenarios I could think of, and it works correctly as far as I can tell, but I could have neglected weird cases. This patch has been very long in the making. The first patch was written by Bernd Helmle in 2010 to add a new pg_constraint.contype value ('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one was killed by the realization that we ought to use contype='c' instead: manufactured CHECK constraints. However, later SQL standard development, as well as nonobvious emergent properties of that design (mostly, failure to distinguish them from "normal" CHECK constraints as well as the performance implication of having to test the CHECK expression) led us to reconsider this choice, so now the current implementation uses contype='n' again. During Postgres 16 this had already been introduced by commit e056c557aef4, but there were some problems mainly with the pg_upgrade procedure that couldn't be fixed in reasonable time, so it was reverted. In 2016 Vitaly Burovoy also worked on this feature[1] but found no consensus for his proposed approach, which was claimed to be closer to the letter of the standard, requiring an additional pg_attribute column to track the OID of the not-null constraint for that column. [1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Author: Bernd Helmle <mailings@oopsware.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
The catalog <structname>pg_constraint</structname> stores check, not-null,
primary key, unique, foreign key, and exclusion constraints on tables.
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
(Column constraints are not treated specially. Every column constraint is
equivalent to some table constraint.)
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</para>
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
<para>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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.
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
2010-01-17 23:56:23 +01:00
</para>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Check constraints on domains are stored here, too.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_constraint</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
The OID of the namespace that contains this constraint
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>contype</structfield> <type>char</type>
</para>
<para>
<literal>c</literal> = check constraint,
<literal>f</literal> = foreign key constraint,
Catalog not-null constraints We now create contype='n' pg_constraint rows for not-null constraints. We propagate these constraints to other tables during operations such as adding inheritance relationships, creating and attaching partitions and creating tables LIKE other tables. We also spawn not-null constraints for inheritance child tables when their parents have primary keys. These related constraints mostly follow the well-known rules of conislocal and coninhcount that we have for CHECK constraints, with some adaptations: for example, as opposed to CHECK constraints, we don't match not-null ones by name when descending a hierarchy to alter it, instead matching by column name that they apply to. This means we don't require the constraint names to be identical across a hierarchy. For now, we omit them for system catalogs. Maybe this is worth reconsidering. We don't support NOT VALID nor DEFERRABLE clauses either; these can be added as separate features later (this patch is already large and complicated enough.) psql shows these constraints in \d+. pg_dump requires some ad-hoc hacks, particularly when dumping a primary key. We now create one "throwaway" not-null constraint for each column in the PK together with the CREATE TABLE command, and once the PK is created, all those throwaway constraints are removed. This avoids having to check each tuple for nullness when the dump restores the primary key creation. pg_upgrading from an older release requires a somewhat brittle procedure to create a constraint state that matches what would be created if the database were being created fresh in Postgres 17. I have tested all the scenarios I could think of, and it works correctly as far as I can tell, but I could have neglected weird cases. This patch has been very long in the making. The first patch was written by Bernd Helmle in 2010 to add a new pg_constraint.contype value ('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one was killed by the realization that we ought to use contype='c' instead: manufactured CHECK constraints. However, later SQL standard development, as well as nonobvious emergent properties of that design (mostly, failure to distinguish them from "normal" CHECK constraints as well as the performance implication of having to test the CHECK expression) led us to reconsider this choice, so now the current implementation uses contype='n' again. During Postgres 16 this had already been introduced by commit e056c557aef4, but there were some problems mainly with the pg_upgrade procedure that couldn't be fixed in reasonable time, so it was reverted. In 2016 Vitaly Burovoy also worked on this feature[1] but found no consensus for his proposed approach, which was claimed to be closer to the letter of the standard, requiring an additional pg_attribute column to track the OID of the not-null constraint for that column. [1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Author: Bernd Helmle <mailings@oopsware.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
<literal>n</literal> = not-null constraint,
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<literal>p</literal> = primary key constraint,
<literal>u</literal> = unique constraint,
<literal>t</literal> = constraint trigger,
<literal>x</literal> = exclusion constraint
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
Additional required docs for pg_constraint catalog entry Noted by Bernd Helmle
2011-02-15 01:59:29 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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?
Doc: clarify description for pg_constraint.convalidated. Jimmy Angelakos Discussion: https://postgr.es/m/CABgVKCW_zPnvFXn24FTF0299_yU6+1p6JRUc0xpiZFWEXH1_jg@mail.gmail.com
2020-10-30 15:38:49 +01:00
Currently, can be false only for foreign keys and CHECK constraints
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Additional required docs for pg_constraint catalog entry Noted by Bernd Helmle
2011-02-15 01:59:29 +01:00
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The table this constraint is on; zero if not a table constraint
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The domain this constraint is on; zero if not a domain constraint
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
key, foreign key, or exclusion constraint; else zero
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
</row>
Allow FOR EACH ROW triggers on partitioned tables Previously, FOR EACH ROW triggers were not allowed in partitioned tables. Now we allow AFTER triggers on them, and on trigger creation we cascade to create an identical trigger in each partition. We also clone the triggers to each partition that is created or attached later. This means that deferred unique keys are allowed on partitioned tables, too. Author: Álvaro Herrera Reviewed-by: Peter Eisentraut, Simon Riggs, Amit Langote, Robert Haas, Thomas Munro Discussion: https://postgr.es/m/20171229225319.ajltgss2ojkfd3kp@alvherre.pgsql
2018-03-23 14:48:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The corresponding constraint of the parent partitioned table,
if this is a constraint on a partition; else zero
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Allow FOR EACH ROW triggers on partitioned tables Previously, FOR EACH ROW triggers were not allowed in partitioned tables. Now we allow AFTER triggers on them, and on trigger creation we cascade to create an identical trigger in each partition. We also clone the triggers to each partition that is created or attached later. This means that deferred unique keys are allowed on partitioned tables, too. Author: Álvaro Herrera Reviewed-by: Peter Eisentraut, Simon Riggs, Amit Langote, Robert Haas, Thomas Munro Discussion: https://postgr.es/m/20171229225319.ajltgss2ojkfd3kp@alvherre.pgsql
2018-03-23 14:48:22 +01:00
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
If a foreign key, the referenced table; else zero
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
This constraint is defined locally for the relation. Note that a
Spell and markup checking
2010-08-17 06:37:21 +02:00
constraint can be locally defined and inherited simultaneously.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Save a few bytes in pg_attribute Change the columns attndims, attstattarget, and attinhcount from int32 to int16, and reorder a bit. This saves some space (currently 4 bytes) in pg_attribute and tuple descriptors, which translates into small performance benefits and/or room for new columns in pg_attribute needed by future features. attndims and attinhcount are never realistically used with values larger than int16. Just to be sure, add some overflow checks. attstattarget is currently limited explicitly to 10000. For consistency, pg_constraint.coninhcount is also changed like attinhcount. Discussion: https://www.postgresql.org/message-id/flat/d07ffc2b-e0e8-77f7-38fb-be921dff71af%40enterprisedb.com
2023-03-28 09:58:14 +02:00
<structfield>coninhcount</structfield> <type>int2</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
The number of direct inheritance ancestors this constraint has.
A constraint with
Spell and markup checking
2010-08-17 06:37:21 +02:00
a nonzero number of ancestors cannot be dropped nor renamed.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Change the rules for inherited CHECK constraints to be essentially the same as those for inherited columns; that is, it's no longer allowed for a child table to not have a check constraint matching one that exists on a parent. This satisfies the principle of least surprise (rows selected from the parent will always appear to meet its check constraints) and eliminates some longstanding bogosity in pg_dump, which formerly had to guess about whether check constraints were really inherited or not. The implementation involves adding conislocal and coninhcount columns to pg_constraint (paralleling attislocal and attinhcount in pg_attribute) and refactoring various ALTER TABLE actions to be more like those for columns. Alex Hunsaker, Nikhil Sontakke, Tom Lane
2008-05-10 01:32:05 +02:00
</row>
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
This constraint is defined locally for the relation. It is a
non-inheritable constraint.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Allow CHECK constraints to be declared ONLY This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
2011-12-05 19:10:18 +01:00
</row>
Add temporal PRIMARY KEY and UNIQUE constraints Add WITHOUT OVERLAPS clause to PRIMARY KEY and UNIQUE constraints. These are backed by GiST indexes instead of B-tree indexes, since they are essentially exclusion constraints with = for the scalar parts of the key and && for the temporal part. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
2024-01-24 15:43:41 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Rename pg_constraint.conwithoutoverlaps to conperiod pg_constraint.conwithoutoverlaps was recently added to support primary keys and unique constraints with the WITHOUT OVERLAPS clause. An upcoming patch provides the foreign-key side of this functionality, but the syntax there is different and uses the keyword PERIOD. It would make sense to use the same pg_constraint field for both of these, but then we should pick a more general name that conveys "this constraint has a temporal/period-related feature". conperiod works for that and is nicely compact. Changing this now avoids possibly having to introduce versioning into clients. Note there are still some "without overlaps" variables left, which deal specifically with the parsing of the primary key/unique constraint feature. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
2024-03-05 11:15:06 +01:00
<structfield>conperiod</structfield> <type>bool</type>
Add temporal PRIMARY KEY and UNIQUE constraints Add WITHOUT OVERLAPS clause to PRIMARY KEY and UNIQUE constraints. These are backed by GiST indexes instead of B-tree indexes, since they are essentially exclusion constraints with = for the scalar parts of the key and && for the temporal part. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
2024-01-24 15:43:41 +01:00
</para>
<para>
This constraint is defined with <literal>WITHOUT OVERLAPS</literal>
Add temporal FOREIGN KEY contraints Add PERIOD clause to foreign key constraint definitions. This is supported for range and multirange types. Temporal foreign keys check for range containment instead of equality. This feature matches the behavior of the SQL standard temporal foreign keys, but it works on PostgreSQL's native ranges instead of SQL's "periods", which don't exist in PostgreSQL (yet). Reference actions ON {UPDATE,DELETE} {CASCADE,SET NULL,SET DEFAULT} are not supported yet. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
2024-03-24 07:37:13 +01:00
(for primary keys and unique constraints) or <literal>PERIOD</literal>
(for foreign keys).
Add temporal PRIMARY KEY and UNIQUE constraints Add WITHOUT OVERLAPS clause to PRIMARY KEY and UNIQUE constraints. These are backed by GiST indexes instead of B-tree indexes, since they are essentially exclusion constraints with = for the scalar parts of the key and && for the temporal part. Author: Paul A. Jungwirth <pj@illuminatedcomputing.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: jian he <jian.universality@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com
2024-01-24 15:43:41 +01:00
</para></entry>
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Improve covering index documentation Add missed description of pg_constraint.conincluding Shinoda, Noriyoshi and Alexander Korotkov
2018-04-09 16:53:42 +02:00
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
</row>
Allow specifying column list for foreign key ON DELETE SET actions Extend the foreign key ON DELETE actions SET NULL and SET DEFAULT by allowing the specification of a column list, like CREATE TABLE posts ( ... FOREIGN KEY (tenant_id, author_id) REFERENCES users ON DELETE SET NULL (author_id) ); If a column list is specified, only those columns are set to null/default, instead of all the columns in the foreign-key constraint. This is useful for multitenant or sharded schemas, where the tenant or shard ID is included in the primary key of all tables but shouldn't be set to null. Author: Paul Martinez <paulmtz@google.com> Discussion: https://www.postgresql.org/message-id/flat/CACqFVBZQyMYJV=njbSMxf+rbDHpx=W=B7AEaMKn8dWn9OZJY7w@mail.gmail.com
2021-12-08 11:09:44 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confdelsetcols</structfield> <type>int2[]</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
If a foreign key with a <literal>SET NULL</literal> or <literal>SET
DEFAULT</literal> delete action, the columns that will be updated.
If null, all of the referencing columns will be updated.
</para></entry>
</row>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
</row>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
</tbody>
</tgroup>
</table>
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Add exclusion constraints, which generalize the concept of uniqueness to support any indexable commutative operator, not just equality. Two rows violate the exclusion constraint if "row1.col OP row2.col" is TRUE for each of the columns in the constraint. Jeff Davis, reviewed by Robert Haas
2009-12-07 06:22:23 +01:00
index.)
</para>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<note>
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>pg_class.relchecks</literal> needs to agree with the
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
number of check-constraint entries found in this table for each
Replace pg_class.relhasexclusion with pg_index.indisexclusion. There isn't any need to track this state on a table-wide basis, and trying to do so introduces undesirable semantic fuzziness. Move the flag to pg_index, where it clearly describes just a single index and can be immutable after index creation.
2011-01-25 23:51:59 +01:00
relation.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</para>
</note>
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<sect1 id="catalog-pg-conversion">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_conversion</structname></title>
<indexterm zone="catalog-pg-conversion">
<primary>pg_conversion</primary>
</indexterm>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<para>
Rephrase pg_conversion description to avoid splitting link across page. The link to the CREATE CONVERSION manual page was split across a page boundary in the PDF output, leading to "\pdfendlink ended up in different nesting level than \pdfstartlink" error while building PDFs. It wouldn't be worth changing text that's undergoing active editing to avoid this, since other editing might result in moving the link away from the page end anyway. But this paragraph has been static for a long time, so might as well fix it to prevent it from being an issue in future.
2011-01-28 00:42:12 +01:00
The catalog <structname>pg_conversion</structname> describes
doc: Update uses of the word "procedure" Historically, the term procedure was used as a synonym for function in Postgres/PostgreSQL. Now we have procedures as separate objects from functions, so we need to clean up the documentation to not mix those terms. In particular, mentions of "trigger procedures" are changed to "trigger functions", and access method "support procedures" are changed to "support functions". (The latter already used FUNCTION in the SQL syntax anyway.) Also, the terminology in the SPI chapter has been cleaned up. A few tests, examples, and code comments are also adjusted to be consistent with documentation changes, but not everything. Reported-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Jonathan S. Katz <jonathan.katz@excoventures.com>
2018-08-15 17:01:39 +02:00
encoding conversion functions. See <xref linkend="sql-createconversion"/>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
for more information.
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_conversion</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
The OID of the namespace that contains this conversion
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Document pg_encoding_to_char() and pg_char_to_encoding(). Previously both functions were not described anywhere in the docs. But since they have been around since 7.0 and mentioned in the description for system catalog like pg_database, it's reasonable to add short descriptions for them. Author: Ian Lawrence Barwick Reviewed-by: Laurenz Albe, Fujii Masao Discussion: https://postgr.es/m/CAB8KJ=infievn4q1N4X7Vx8w4_RMPPG0pLvxhSDjy5WQOSHW9g@mail.gmail.com
2021-10-05 05:52:51 +02:00
Source encoding ID (<link linkend="pg-encoding-to-char"><function>pg_encoding_to_char()</function></link>
can translate this number to the encoding name)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Document pg_encoding_to_char() and pg_char_to_encoding(). Previously both functions were not described anywhere in the docs. But since they have been around since 7.0 and mentioned in the description for system catalog like pg_database, it's reasonable to add short descriptions for them. Author: Ian Lawrence Barwick Reviewed-by: Laurenz Albe, Fujii Masao Discussion: https://postgr.es/m/CAB8KJ=infievn4q1N4X7Vx8w4_RMPPG0pLvxhSDjy5WQOSHW9g@mail.gmail.com
2021-10-05 05:52:51 +02:00
Destination encoding ID (<link linkend="pg-encoding-to-char"><function>pg_encoding_to_char()</function></link>
can translate this number to the encoding name)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-database">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_database</structname></title>
<indexterm zone="catalog-pg-database">
<primary>pg_database</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
Consult <xref linkend="managing-databases"/> for details about the meaning
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
of some of the parameters.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_database</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
doc: Document pg_encoding_to_char() and pg_char_to_encoding(). Previously both functions were not described anywhere in the docs. But since they have been around since 7.0 and mentioned in the description for system catalog like pg_database, it's reasonable to add short descriptions for them. Author: Ian Lawrence Barwick Reviewed-by: Laurenz Albe, Fujii Masao Discussion: https://postgr.es/m/CAB8KJ=infievn4q1N4X7Vx8w4_RMPPG0pLvxhSDjy5WQOSHW9g@mail.gmail.com
2021-10-05 05:52:51 +02:00
(<link linkend="pg-encoding-to-char"><function>pg_encoding_to_char()</function></link> can translate
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
this number to the encoding name)
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
doc: Add documentation for pg_database.datlocprovider column This was apparently missed in the original commit. Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> Discussion: https://www.postgresql.org/message-id/flat/DM4PR84MB1734BA51BC8B08CF3FA239BBEED49%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2022-05-23 10:31:33 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datlocprovider</structfield> <type>char</type>
</para>
<para>
Locale provider for this database: <literal>c</literal> = libc,
<literal>i</literal> = icu
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
docs: clearify use of pg_database.datistemplate Patch by Rajeev rastogi
2014-04-23 00:10:14 +02:00
If true, then this database can be cloned by
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
any user with <literal>CREATEDB</literal> privileges;
docs: clearify use of pg_database.datistemplate Patch by Rajeev rastogi
2014-04-23 00:10:14 +02:00
if false, then only superusers or the owner of
the database can clone it.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
If false then no one can connect to this database. This is
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
used to protect the <literal>template0</literal> database from being altered.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Add support event triggers on authenticated login This commit introduces trigger on login event, allowing to fire some actions right on the user connection. This can be useful for logging or connection check purposes as well as for some personalization of environment. Usage details are described in the documentation included, but shortly usage is the same as for other triggers: create function returning event_trigger and then create event trigger on login event. In order to prevent the connection time overhead when there are no triggers the commit introduces pg_database.dathasloginevt flag, which indicates database has active login triggers. This flag is set by CREATE/ALTER EVENT TRIGGER command, and unset at connection time when no active triggers found. Author: Konstantin Knizhnik, Mikhail Gribkov Discussion: https://postgr.es/m/0d46d29f-4558-3af9-9c85-7774e14a7709%40postgrespro.ru Reviewed-by: Pavel Stehule, Takayuki Tsunakawa, Greg Nancarrow, Ivan Panchenko Reviewed-by: Daniel Gustafsson, Teodor Sigaev, Robert Haas, Andres Freund Reviewed-by: Tom Lane, Andrey Sokolov, Zhihong Yu, Sergey Shinderuk Reviewed-by: Gregory Stark, Nikita Malakhov, Ted Yu
2023-10-16 02:16:55 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>dathasloginevt</structfield> <type>bool</type>
</para>
<para>
Indicates that there are login event triggers defined for this database.
This flag is used to avoid extra lookups on the
<structname>pg_event_trigger</structname> table during each backend
startup. This flag is used internally by <productname>PostgreSQL</productname>
and should not be manually altered or read for monitoring purposes.
</para></entry>
</row>
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datconnlimit</structfield> <type>int4</type>
</para>
<para>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType() with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
2008-07-30 19:05:05 +02:00
Sets maximum number of concurrent connections that can be made
Handle DROP DATABASE getting interrupted Until now, when DROP DATABASE got interrupted in the wrong moment, the removal of the pg_database row would also roll back, even though some irreversible steps have already been taken. E.g. DropDatabaseBuffers() might have thrown out dirty buffers, or files could have been unlinked. But we continued to allow connections to such a corrupted database. To fix this, mark databases invalid with an in-place update, just before starting to perform irreversible steps. As we can't add a new column in the back branches, we use pg_database.datconnlimit = -2 for this purpose. An invalid database cannot be connected to anymore, but can still be dropped. Unfortunately we can't easily add output to psql's \l to indicate that some database is invalid, it doesn't fit in any of the existing columns. Add tests verifying that a interrupted DROP DATABASE is handled correctly in the backend and in various tools. Reported-by: Evgeny Morozov <postgresql3@realityexists.net> Author: Andres Freund <andres@anarazel.de> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de Backpatch: 11-, bug present in all supported versions
2023-07-13 22:03:28 +02:00
to this database. -1 means no limit, -2 indicates the database is
invalid.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add per-user and per-database connection limit options. This patch also includes preliminary update of pg_dumpall for roles. Petr Jelinek, with review by Bruce Momjian and Tom Lane.
2005-07-31 19:19:22 +02:00
</row>
Transaction IDs wrap around, per my proposal of 13-Aug-01. More documentation to come, but the code is all here. initdb forced.
2001-08-26 18:56:03 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relfrozenxid</structfield> values.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Transaction IDs wrap around, per my proposal of 13-Aug-01. More documentation to come, but the code is all here. initdb forced.
2001-08-26 18:56:03 +02:00
</row>
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
2013-06-27 21:20:33 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix some issues in pg_class.relminmxid and pg_database.datminmxid documentation. - Correct the name of directory which those catalog columns allow to be shrunk. - Correct the name of symbol which is used as the value of pg_class.relminmxid when the relation is not a table. - Fix "ID ID" typo. Backpatch to 9.3 where those cataog columns were introduced.
2015-06-04 06:22:49 +02:00
All multixact IDs before this one have been replaced with a
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
multixact ID wraparound or to allow <literal>pg_multixact</literal> to be shrunk.
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
2013-06-27 21:20:33 +02:00
It is the minimum of the per-table
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relminmxid</structfield> values.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Document relminmxid and datminmxid I introduced these new fields in 0ac5ad5134f27 but neglected to add them to the system catalogs section of the docs. Per Thom Brown in message CAA-aLv7UiO=Whiq3MVbsEqSyQRthuX8Tb_RLyBuQt0KQBp=6EQ@mail.gmail.com
2013-06-27 21:20:33 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
The default tablespace for the database.
Within this database, all tables for which
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>reltablespace</structfield> is zero
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
will be stored in this tablespace; in particular, all the non-shared
Spell and markup checking
2010-08-17 06:37:21 +02:00
system catalogs will be there.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
User and database-specific session defaults for run-time configuration variables. New commands ALTER DATABASE ... SET and ALTER USER ... SET.
2002-03-01 23:45:19 +01:00
Change collate and ctype fields to type text This changes the data type of the catalog fields datcollate, datctype, collcollate, and collctype from name to text. There wasn't ever a really good reason for them to be of type name; presumably this was just carried over from when they were fixed-size fields in pg_control, first into the corresponding pg_database fields, and then to pg_collation. The values are not identifiers or object names, and we don't ever look them up that way. Changing to type text saves space in the typical case, since locale names are typically only a few bytes long. But it is also possible that an ICU locale name with several customization options appended could be longer than 63 bytes, so this also enables that case, which was previously probably broken. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a@2ndquadrant.com
2022-01-27 08:44:31 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datcollate</structfield> <type>text</type>
</para>
<para>
LC_COLLATE for this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datctype</structfield> <type>text</type>
</para>
<para>
LC_CTYPE for this database
</para></entry>
</row>
Database-level collation version tracking This adds to database objects the same version tracking that collation objects have. There is a new pg_database column datcollversion that stores the version, a new function pg_database_collation_actual_version() to get the version from the operating system, and a new subcommand ALTER DATABASE ... REFRESH COLLATION VERSION. This was not originally added together with pg_collation.collversion, since originally version tracking was only supported for ICU, and ICU on a database-level is not currently supported. But we now have version tracking for glibc (since PG13), FreeBSD (since PG14), and Windows (since PG13), so this is useful to have now. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/f0ff3190-29a3-5b39-a179-fa32eee57db6%40enterprisedb.com
2022-02-14 08:09:04 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Catalog changes preparing for builtin collation provider. Rename pg_collation.colliculocale to colllocale, and pg_database.daticulocale to datlocale. These names reflects that the fields will be useful for the upcoming builtin provider as well, not just for ICU. This is purely a rename; no changes to the meaning of the fields. Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com Reviewed-by: Peter Eisentraut
2024-03-09 23:48:18 +01:00
<structfield>datlocale</structfield> <type>text</type>
doc: Add documentation for new field pg_database.daticulocale forgotten in f2553d43060edb210b36c63187d52a632448e1d2 Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
2022-03-17 14:12:03 +01:00
</para>
<para>
Catalog changes preparing for builtin collation provider. Rename pg_collation.colliculocale to colllocale, and pg_database.daticulocale to datlocale. These names reflects that the fields will be useful for the upcoming builtin provider as well, not just for ICU. This is purely a rename; no changes to the meaning of the fields. Discussion: https://postgr.es/m/ff4c2f2f9c8fc7ca27c1c24ae37ecaeaeaff6b53.camel%40j-davis.com Reviewed-by: Peter Eisentraut
2024-03-09 23:48:18 +01:00
Collation provider locale name for this database. If the
provider is <literal>libc</literal>,
<structfield>datlocale</structfield> is <literal>NULL</literal>;
<structfield>datcollate</structfield> and
<structfield>datctype</structfield> are used instead.
doc: Add documentation for new field pg_database.daticulocale forgotten in f2553d43060edb210b36c63187d52a632448e1d2 Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
2022-03-17 14:12:03 +01:00
</para></entry>
</row>
Allow tailoring of ICU locales with custom rules This exposes the ICU facility to add custom collation rules to a standard collation. New options are added to CREATE COLLATION, CREATE DATABASE, createdb, and initdb to set the rules. Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: Daniel Verite <daniel@manitou-mail.org> Discussion: https://www.postgresql.org/message-id/flat/821c71a4-6ef0-d366-9acf-bb8e367f739f@enterprisedb.com
2023-03-08 16:35:42 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>daticurules</structfield> <type>text</type>
</para>
<para>
ICU collation rules for this database
</para></entry>
</row>
doc: Add documentation for new field pg_database.daticulocale forgotten in f2553d43060edb210b36c63187d52a632448e1d2 Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
2022-03-17 14:12:03 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Database-level collation version tracking This adds to database objects the same version tracking that collation objects have. There is a new pg_database column datcollversion that stores the version, a new function pg_database_collation_actual_version() to get the version from the operating system, and a new subcommand ALTER DATABASE ... REFRESH COLLATION VERSION. This was not originally added together with pg_collation.collversion, since originally version tracking was only supported for ICU, and ICU on a database-level is not currently supported. But we now have version tracking for glibc (since PG13), FreeBSD (since PG14), and Windows (since PG13), so this is useful to have now. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/f0ff3190-29a3-5b39-a179-fa32eee57db6%40enterprisedb.com
2022-02-14 08:09:04 +01:00
<structfield>datcollversion</structfield> <type>text</type>
</para>
<para>
Provider-specific version of the collation. This is recorded when the
database is created and then checked when it is used, to detect
changes in the collation definition that could lead to data corruption.
</para></entry>
</row>
Restructure AclItem representation so that we can have more than eight different privilege bits (might as well make use of the space we were wasting on padding). EXECUTE and USAGE bits for procedures, languages now are separate privileges instead of being overlaid on SELECT. Add privileges for namespaces and databases. The GRANT and REVOKE commands work for these object types, but we don't actually enforce the privileges yet...
2002-04-21 02:26:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Restructure AclItem representation so that we can have more than eight different privilege bits (might as well make use of the space we were wasting on padding). EXECUTE and USAGE bits for procedures, languages now are separate privileges instead of being overlaid on SELECT. Add privileges for namespaces and databases. The GRANT and REVOKE commands work for these object types, but we don't actually enforce the privileges yet...
2002-04-21 02:26:44 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Move pg_db_role_setting docs to correct place in alphabetical order.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_db_role_setting</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Move pg_db_role_setting docs to correct place in alphabetical order.
2010-09-17 20:49:54 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Move pg_db_role_setting docs to correct place in alphabetical order.
2010-09-17 20:49:54 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Move pg_db_role_setting docs to correct place in alphabetical order.
2010-09-17 20:49:54 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Move pg_db_role_setting docs to correct place in alphabetical order.
2010-09-17 20:49:54 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Move pg_db_role_setting docs to correct place in alphabetical order.
2010-09-17 20:49:54 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_default_acl</structname> stores initial
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
privileges to be assigned to newly created objects.
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_default_acl</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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,
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
Type of object this entry is for:
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>r</literal> = relation (table, view),
<literal>S</literal> = sequence,
<literal>f</literal> = function,
Add 'n' to list of possible values to pg_default_acl.defaclobjtype This was missed in commit ab89e465cb20; backpatch to v10. Author: Fabien Coelho <coelho@cri.ensmp.fr> Discussion: https://postgr.es/m/alpine.DEB.2.21.1807302243001.13230@lancre
2018-08-03 22:45:08 +02:00
<literal>T</literal> = type,
<literal>n</literal> = schema
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
Access privileges that this type of object should have on creation
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
A <structname>pg_default_acl</structname> entry shows the initial privileges to
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
be assigned to an object belonging to the indicated user. There are
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
currently two types of entry: <quote>global</quote> entries with
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
<structfield>defaclnamespace</structfield> = zero, and <quote>per-schema</quote> entries
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
that reference a particular schema. If a global entry is present then
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
it <emphasis>overrides</emphasis> the normal hard-wired default privileges
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
for the object type. A per-schema entry, if present, represents privileges
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
to be <emphasis>added to</emphasis> the global or hard-wired default privileges.
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
</para>
<para>
Spell and markup checking
2010-08-17 06:37:21 +02:00
Note that when an ACL entry in another catalog is null, it is taken
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
to represent the hard-wired default privileges for its object,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Create an ALTER DEFAULT PRIVILEGES command, which allows users to adjust the privileges that will be applied to subsequently-created objects. Such adjustments are always per owning role, and can be restricted to objects created in particular schemas too. A notable benefit is that users can override the traditional default privilege settings, eg, the PUBLIC EXECUTE privilege traditionally granted by default for functions. Petr Jelinek
2009-10-05 21:24:49 +02:00
object creation.
</para>
</sect1>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<sect1 id="catalog-pg-depend">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_depend</structname></title>
<indexterm zone="catalog-pg-depend">
<primary>pg_depend</primary>
</indexterm>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_depend</structname> records the dependency
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
relationships between database objects. This information allows
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</para>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_depend</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace explicit PIN entries in pg_depend with an OID range test. As of v14, pg_depend contains almost 7000 "pin" entries recording the OIDs of built-in objects. This is a fair amount of bloat for every database, and it adds time to pg_depend lookups as well as initdb. We can get rid of all of those entries in favor of an OID range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned". (template1 and the public schema are exceptions. Those exceptions are now wired into IsPinnedObject() instead of initdb's code for filling pg_depend, but it's the same amount of cruft either way.) The contents of pg_shdepend are modified likewise. Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
2021-07-15 17:41:47 +02:00
The OID of the system catalog the dependent object is in
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace explicit PIN entries in pg_depend with an OID range test. As of v14, pg_depend contains almost 7000 "pin" entries recording the OIDs of built-in objects. This is a fair amount of bloat for every database, and it adds time to pg_depend lookups as well as initdb. We can get rid of all of those entries in favor of an OID range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned". (template1 and the public schema are exceptions. Those exceptions are now wired into IsPinnedObject() instead of initdb's code for filling pg_depend, but it's the same amount of cruft either way.) The contents of pg_shdepend are modified likewise. Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
2021-07-15 17:41:47 +02:00
The OID of the specific dependent object
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
For a table column, this is the column number (the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>objid</structfield> and <structfield>classid</structfield> refer to the
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
table itself). For all other object types, this column is
Spell and markup checking
2010-08-17 06:37:21 +02:00
zero.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
For a table column, this is the column number (the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>refobjid</structfield> and <structfield>refclassid</structfield> refer
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
to the table itself). For all other object types, this column
Spell and markup checking
2010-08-17 06:37:21 +02:00
is zero.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Change the parameter_types column of the pg_prepared_statements to be an array of regtype, rather than an array of OIDs. This is likely to be more useful to user, and the type OID can easily be obtained by casting a regtype value to OID. Per suggestion from Tom. Update the documentation and regression tests, and bump the catversion.
2006-01-16 19:15:31 +01:00
A code defining the specific semantics of this dependency relationship; see text
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
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
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
object. However, there are several subflavors identified by
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>deptype</structfield>:
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<variablelist>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_NORMAL</symbol> (<literal>n</literal>)</term>
Add better markup and improve some text here and there.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
by specifying <literal>CASCADE</literal>, in which case the dependent
Add better markup and improve some text here and there.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_AUTO</symbol> (<literal>a</literal>)</term>
Add better markup and improve some text here and there.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
(regardless of <literal>RESTRICT</literal> or <literal>CASCADE</literal>
Add better markup and improve some text here and there.
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
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
that it will go away if the table is dropped.
</para>
</listitem>
</varlistentry>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_INTERNAL</symbol> (<literal>i</literal>)</term>
Add better markup and improve some text here and there.
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
Doc: Improve wording of multiple places in documentation This has been found during its translation. Author: Liudmila Mantrova Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com Backpatch-through: 12
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.
Add better markup and improve some text here and there.
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_EXTENSION</symbol> (<literal>e</literal>)</term>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
<listitem>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The dependent object is a member of the <firstterm>extension</firstterm> that is
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
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>.
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</para>
</listitem>
</varlistentry>
Support ALTER THING .. DEPENDS ON EXTENSION This introduces a new dependency type which marks an object as depending on an extension, such that if the extension is dropped, the object automatically goes away; and also, if the database is dumped, the object is included in the dump output. Currently the grammar supports this for indexes, triggers, materialized views and functions only, although the utility code is generic so adding support for more object types is a matter of touching the parser rules only. Author: Abhijit Menon-Sen Reviewed-by: Alexander Korotkov, Álvaro Herrera Discussion: http://www.postgresql.org/message-id/20160115062649.GA5068@toroid.org
2016-04-05 23:38:54 +02:00
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>DEPENDENCY_AUTO_EXTENSION</symbol> (<literal>x</literal>)</term>
Support ALTER THING .. DEPENDS ON EXTENSION This introduces a new dependency type which marks an object as depending on an extension, such that if the extension is dropped, the object automatically goes away; and also, if the database is dumped, the object is included in the dump output. Currently the grammar supports this for indexes, triggers, materialized views and functions only, although the utility code is generic so adding support for more object types is a matter of touching the parser rules only. Author: Abhijit Menon-Sen Reviewed-by: Alexander Korotkov, Álvaro Herrera Discussion: http://www.postgresql.org/message-id/20160115062649.GA5068@toroid.org
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>.
Support ALTER THING .. DEPENDS ON EXTENSION This introduces a new dependency type which marks an object as depending on an extension, such that if the extension is dropped, the object automatically goes away; and also, if the database is dumped, the object is included in the dump output. Currently the grammar supports this for indexes, triggers, materialized views and functions only, although the utility code is generic so adding support for more object types is a matter of touching the parser rules only. Author: Abhijit Menon-Sen Reviewed-by: Alexander Korotkov, Álvaro Herrera Discussion: http://www.postgresql.org/message-id/20160115062649.GA5068@toroid.org
2016-04-05 23:38:54 +02:00
</para>
</listitem>
</varlistentry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
</variablelist>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
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.
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
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>
Replace explicit PIN entries in pg_depend with an OID range test. As of v14, pg_depend contains almost 7000 "pin" entries recording the OIDs of built-in objects. This is a fair amount of bloat for every database, and it adds time to pg_depend lookups as well as initdb. We can get rid of all of those entries in favor of an OID range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned". (template1 and the public schema are exceptions. Those exceptions are now wired into IsPinnedObject() instead of initdb's code for filling pg_depend, but it's the same amount of cruft either way.) The contents of pg_shdepend are modified likewise. Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
2021-07-15 17:41:47 +02:00
<para>
Most objects created during <application>initdb</application> are
considered <quote>pinned</quote>, which means that the system itself
depends on them. Therefore, they are never allowed to be dropped.
Also, knowing that pinned objects will not be dropped, the dependency
mechanism doesn't bother to make <structname>pg_depend</structname>
entries showing dependencies on them. Thus, for example, a table
column of type <type>numeric</type> notionally has
a <literal>NORMAL</literal> dependency on the <type>numeric</type>
data type, but no such entry actually appears
in <structname>pg_depend</structname>.
</para>
Second phase of committing Rod Taylor's pg_depend/pg_constraint patch. pg_relcheck is gone; CHECK, UNIQUE, PRIMARY KEY, and FOREIGN KEY constraints all have real live entries in pg_constraint. pg_depend exists, and RESTRICT/CASCADE options work on most kinds of DROP; however, pg_depend is not yet very well populated with dependencies. (Most of the ones that are present at this point just replace formerly hardwired associations, such as the implicit drop of a relation's pg_type entry when the relation is dropped.) Need to add more logic to create dependency entries, improve pg_dump to dump constraints in place of indexes and triggers, and add some regression tests.
2002-07-12 20:43:19 +02:00
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-description">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_description</structname></title>
<indexterm zone="catalog-pg-description">
<primary>pg_description</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_description</structname> stores optional descriptions
More minor updates and copy-editing.
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
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<application>psql</application>'s <literal>\d</literal> commands.
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
Descriptions of many built-in system objects are provided in the initial
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
contents of <structname>pg_description</structname>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_description</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
2001-08-10 20:57:42 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
2001-08-10 20:57:42 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
For a comment on a table column, this is the column number (the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>objoid</structfield> and <structfield>classoid</structfield> refer to
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
the table itself). For all other object types, this column is
Spell and markup checking
2010-08-17 06:37:21 +02:00
zero.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make OIDs optional, per discussions in pghackers. WITH OIDS is still the default, but OIDS are removed from many system catalogs that don't need them. Some interesting side effects: TOAST pointers are 20 bytes not 32 now; pg_description has a three-column key instead of one. Bugs fixed in passing: BINARY cursors work again; pg_class.relhaspkey has some usefulness; pg_dump dumps comments on indexes, rules, and triggers in a valid order. initdb forced.
2001-08-10 20:57:42 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
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
Allow new values to be added to an existing enum type. After much expenditure of effort, we've got this to the point where the performance penalty is pretty minimal in typical cases. Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane
2010-10-25 05:04:37 +02:00
showing the values and labels for each enum type. The
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
internal representation of a given enum value is actually the OID
Allow new values to be added to an existing enum type. After much expenditure of effort, we've got this to the point where the performance penalty is pretty minimal in typical cases. Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane
2010-10-25 05:04:37 +02:00
of its associated row in <structname>pg_enum</structname>.
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_enum</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
</row>
Allow new values to be added to an existing enum type. After much expenditure of effort, we've got this to the point where the performance penalty is pretty minimal in typical cases. Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane
2010-10-25 05:04:37 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow new values to be added to an existing enum type. After much expenditure of effort, we've got this to the point where the performance penalty is pretty minimal in typical cases. Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane
2010-10-25 05:04:37 +02:00
</row>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
</row>
</tbody>
</tgroup>
</table>
Allow new values to be added to an existing enum type. After much expenditure of effort, we've got this to the point where the performance penalty is pretty minimal in typical cases. Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
positions 1..<replaceable>n</replaceable>. But members added later might be given
Allow new values to be added to an existing enum type. After much expenditure of effort, we've got this to the point where the performance penalty is pretty minimal in typical cases. Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane
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>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
</sect1>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
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.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
See <xref linkend="event-triggers"/> for more information.
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_event_trigger</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
</thead>
<tbody>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
</row>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
Controls in which <xref linkend="guc-session-replication-role"/> modes
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
the event trigger fires.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix alphabetization in catalogs.sgml. Some recent patches seem not to have grasped the concept that the catalogs are described in alphabetical order.
2013-12-30 19:27:51 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
about the installed extensions. See <xref linkend="extend-extensions"/>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
for details about extensions.
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_extension</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
2011-02-08 22:08:41 +01:00
</tbody>
</tgroup>
</table>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Note that unlike most catalogs with a <quote>namespace</quote> column,
Core support for "extensions", which are packages of SQL objects. This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make all the contrib modules depend on this feature. In passing, fix a disturbingly large amount of breakage in AlterObjectNamespace() and callers. Dimitri Fontaine, reviewed by Anssi Kääriäinen, Itagaki Takahiro, Tom Lane, and numerous others
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_foreign_data_wrapper</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
2011-02-19 06:06:18 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
2011-02-19 06:06:18 +01:00
</row>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add the possibility to specify an explicit validator function for foreign-data wrappers (similar to procedural languages). This way we don't need to retain the nearly empty libraries, and we are more free in how to implement the wrapper API in the future.
2009-02-24 11:06:36 +01:00
References a validator function that is responsible for
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
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
Add the possibility to specify an explicit validator function for foreign-data wrappers (similar to procedural languages). This way we don't need to retain the nearly empty libraries, and we are more free in how to implement the wrapper API in the future.
2009-02-24 11:06:36 +01:00
mappings using the foreign-data wrapper. Zero if no validator
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
2011-02-19 06:06:18 +01:00
is provided
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Foreign-data wrapper specific options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
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
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
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
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
servers are accessed via foreign-data wrappers.
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_foreign_server</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Foreign server specific options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
SQL/MED catalog manipulation facilities This doesn't do any remote or external things yet, but it gives modules like plproxy and dblink a standardized and future-proof system for managing their connection information. Martin Pihlak and Peter Eisentraut
2008-12-19 17:25:19 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
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>
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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>
Create the catalog infrastructure for foreign-data-wrapper handlers. Add a fdwhandler column to pg_foreign_data_wrapper, plus HANDLER options in the CREATE FOREIGN DATA WRAPPER and ALTER FOREIGN DATA WRAPPER commands, plus pg_dump support for same. Also invent a new pseudotype fdw_handler with properties similar to language_handler. This is split out of the "FDW API" patch for ease of review; it's all stuff we will certainly need, regardless of any other details of the FDW API. FDW handler functions will not actually get called yet. In passing, fix some omissions and infelicities in foreigncmds.c. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
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.
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_foreign_table</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Foreign table options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Basic foreign table support. Foreign tables are a core component of SQL/MED. This commit does not provide a working SQL/MED infrastructure, because foreign tables cannot yet be queried. Support for foreign table scans will need to be added in a future patch. However, this patch creates the necessary system catalog structure, syntax support, and support for ancillary operations such as COMMENT and SECURITY LABEL. Shigeru Hanada, heavily revised by Robert Haas
2011-01-02 05:48:11 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-index">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_index</structname></title>
<indexterm zone="catalog-pg-index">
<primary>pg_index</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_index</structname> contains part of the information
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
about indexes. The rest is mostly in
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_index</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Indexes with INCLUDE columns and their support in B-tree This patch introduces INCLUDE clause to index definition. This clause specifies a list of columns which will be included as a non-key part in the index. The INCLUDE columns exist solely to allow more queries to benefit from index-only scans. Also, such columns don't need to have appropriate operator classes. Expressions are not supported as INCLUDE columns since they cannot be used in index-only scans. Index access methods supporting INCLUDE are indicated by amcaninclude flag in IndexAmRoutine. For now, only B-tree indexes support INCLUDE clause. In B-tree indexes INCLUDE columns are truncated from pivot index tuples (tuples located in non-leaf pages and high keys). Therefore, B-tree indexes now might have variable number of attributes. This patch also provides generic facility to support that: pivot tuples contain number of their attributes in t_tid.ip_posid. Free 13th bit of t_info is used for indicating that. This facility will simplify further support of index suffix truncation. The changes of above are backward-compatible, pg_upgrade doesn't need special handling of B-tree indexes for that. Bump catalog version Author: Anastasia Lubennikova with contribition by Alexander Korotkov and me Reviewed by: Peter Geoghegan, Tomas Vondra, Antonin Houska, Jeff Janes, David Rowley, Alexander Korotkov Discussion: https://www.postgresql.org/message-id/flat/56168952.4010101@postgrespro.ru
2018-04-07 22:00:39 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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,
Drop the rule against included index columns duplicating key columns. The initial version of the included-index-column feature stated that included columns couldn't be the same as any key column of the index. While it'd be pretty silly to do that, since the included column would be entirely redundant, we've never prohibited redundant index columns before so it's not very consistent to do so here. Moreover, the prohibition was itself badly implemented, so that it failed to reject columns that were effectively identical but not spelled quite alike, as reported by Aditya Toshniwal. (Moreover, it's not hard to imagine that for some non-btree index types, such cases would be non-silly anyhow: the index might use a lossy representation for key columns but be able to support retrieval of the original form of included columns.) Hence, let's just drop the prohibition. In passing, do some copy-editing on the documentation for the included-column feature. Yugo Nagata; documentation and test corrections by me Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com
2018-07-18 20:43:03 +02:00
not counting any <firstterm>included columns</firstterm>, which are
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
merely stored and do not participate in the index semantics
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Add UNIQUE null treatment option The SQL standard has been ambiguous about whether null values in unique constraints should be considered equal or not. Different implementations have different behaviors. In the SQL:202x draft, this has been formalized by making this implementation-defined and adding an option on unique constraint definitions UNIQUE [ NULLS [NOT] DISTINCT ] to choose a behavior explicitly. This patch adds this option to PostgreSQL. The default behavior remains UNIQUE NULLS DISTINCT. Making this happen in the btree code is pretty easy; most of the patch is just to carry the flag around to all the places that need it. The CREATE UNIQUE INDEX syntax extension is not from the standard, it's my own invention. I named all the internal flags, catalog columns, etc. in the negative ("nulls not distinct") so that the default PostgreSQL behavior is the default if the flag is false. Reviewed-by: Maxim Orlov <orlovmg@gmail.com> Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/84e5ee1b-387e-9a54-c326-9082674bde78@enterprisedb.com
2022-02-03 11:29:54 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indnullsnotdistinct</structfield> <type>bool</type>
</para>
<para>
This value is only used for unique indexes. If false, this unique
index will consider null values distinct (so the index can contain
multiple null values in a column, the default PostgreSQL behavior). If
it is true, it will consider null values to be equal (so the index can
only contain one null value in a column).
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Replace pg_class.relhasexclusion with pg_index.indisexclusion. There isn't any need to track this state on a table-wide basis, and trying to do so introduces undesirable semantic fuzziness. Move the flag to pg_index, where it clearly describes just a single index and can be immutable after index creation.
2011-01-25 23:51:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace pg_class.relhasexclusion with pg_index.indisexclusion. There isn't any need to track this state on a table-wide basis, and trying to do so introduces undesirable semantic fuzziness. Move the flag to pg_index, where it clearly describes just a single index and can be immutable after index creation.
2011-01-25 23:51:59 +01:00
</row>
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Replace pg_class.relhasexclusion with pg_index.indisexclusion. There isn't any need to track this state on a table-wide basis, and trying to do so introduces undesirable semantic fuzziness. Move the flag to pg_index, where it clearly describes just a single index and can be immutable after index creation.
2011-01-25 23:51:59 +01:00
insertion
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
(irrelevant if <structfield>indisunique</structfield> is not true)
</para></entry>
Support deferrable uniqueness constraints. The current implementation fires an AFTER ROW trigger for each tuple that looks like it might be non-unique according to the index contents at the time of insertion. This works well as long as there aren't many conflicts, but won't scale to massive unique-key reassignments. Improving that case is a TODO item. Dean Rasheed
2009-07-29 22:56:21 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
</row>
Add the ability to create indexes 'concurrently', that is, without blocking concurrent writes to the table. Greg Stark, with a little help from Tom Lane.
2006-08-25 06:06:58 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add the ability to create indexes 'concurrently', that is, without blocking concurrent writes to the table. Greg Stark, with a little help from Tom Lane.
2006-08-25 06:06:58 +02:00
</row>
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>
doc: add section about heap-only tuples (HOT) Reported-by: Jonathan S. Katz Discussion: https://postgr.es/m/c59ffbd5-96ac-a5a5-a401-14f627ca1405@postgresql.org Backpatch-through: 11
2022-08-12 21:05:13 +02:00
event horizon, because the table may contain broken <link linkend="storage-hot">HOT chains</link> with
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
incompatible rows that they can see
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
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>
Spell and markup checking
2010-08-17 06:37:21 +02:00
operations.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add the notion of REPLICA IDENTITY for a table. Pending patches for logical replication will use this to determine which columns of a tuple ought to be considered as its candidate key. Andres Freund, with minor, mostly cosmetic adjustments by me
2013-11-08 18:30:43 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
If true this index has been chosen as <quote>replica identity</quote>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
using <link linkend="sql-altertable-replica-identity"><command>ALTER TABLE ...
REPLICA IDENTITY USING INDEX ...</command></link>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add the notion of REPLICA IDENTITY for a table. Pending patches for logical replication will use this to determine which columns of a tuple ought to be considered as its candidate key. Andres Freund, with minor, mostly cosmetic adjustments by me
2013-11-08 18:30:43 +01:00
</row>
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
This is an array of <structfield>indnatts</structfield> values that
Allow specifying column lists for logical replication This allows specifying an optional column list when adding a table to logical replication. The column list may be specified after the table name, enclosed in parentheses. Columns not included in this list are not sent to the subscriber, allowing the schema on the subscriber to be a subset of the publisher schema. For UPDATE/DELETE publications, the column list needs to cover all REPLICA IDENTITY columns. For INSERT publications, the column list is arbitrary and may omit some REPLICA IDENTITY columns. Furthermore, if the table uses REPLICA IDENTITY FULL, column list is not allowed. The column list can contain only simple column references. Complex expressions, function calls etc. are not allowed. This restriction could be relaxed in the future. During the initial table synchronization, only columns included in the column list are copied to the subscriber. If the subscription has several publications, containing the same table with different column lists, columns specified in any of the lists will be copied. This means all columns are replicated if the table has no column list at all (which is treated as column list with all columns), or when of the publications is defined as FOR ALL TABLES (possibly IN SCHEMA that matches the schema of the table). For partitioned tables, publish_via_partition_root determines whether the column list for the root or the leaf relation will be used. If the parameter is 'false' (the default), the list defined for the leaf relation is used. Otherwise, the column list for the root partition will be used. Psql commands \dRp+ and \d <table-name> now display any column lists. Author: Tomas Vondra, Alvaro Herrera, Rahila Syed Reviewed-by: Peter Eisentraut, Alvaro Herrera, Vignesh C, Ibrar Ahmed, Amit Kapila, Hou zj, Peter Smith, Wang wei, Tang, Shi yu Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
2022-03-26 00:45:21 +01:00
indicate which table columns this index indexes. For example, a value
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
of <literal>1 3</literal> would mean that the first and the third table
Drop the rule against included index columns duplicating key columns. The initial version of the included-index-column feature stated that included columns couldn't be the same as any key column of the index. While it'd be pretty silly to do that, since the included column would be entirely redundant, we've never prohibited redundant index columns before so it's not very consistent to do so here. Moreover, the prohibition was itself badly implemented, so that it failed to reject columns that were effectively identical but not spelled quite alike, as reported by Aditya Toshniwal. (Moreover, it's not hard to imagine that for some non-btree index types, such cases would be non-silly anyhow: the index might use a lossy representation for key columns but be able to support retrieval of the original form of included columns.) Hence, let's just drop the prohibition. In passing, do some copy-editing on the documentation for the included-column feature. Yugo Nagata; documentation and test corrections by me Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com
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
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
corresponding index attribute is an expression over the table columns,
Spell and markup checking
2010-08-17 06:37:21 +02:00
rather than a simple column reference.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
</row>
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Drop the rule against included index columns duplicating key columns. The initial version of the included-index-column feature stated that included columns couldn't be the same as any key column of the index. While it'd be pretty silly to do that, since the included column would be entirely redundant, we've never prohibited redundant index columns before so it's not very consistent to do so here. Moreover, the prohibition was itself badly implemented, so that it failed to reject columns that were effectively identical but not spelled quite alike, as reported by Aditya Toshniwal. (Moreover, it's not hard to imagine that for some non-btree index types, such cases would be non-silly anyhow: the index might use a lossy representation for key columns but be able to support retrieval of the original form of included columns.) Hence, let's just drop the prohibition. In passing, do some copy-editing on the documentation for the included-column feature. Yugo Nagata; documentation and test corrections by me Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
</row>
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Drop the rule against included index columns duplicating key columns. The initial version of the included-index-column feature stated that included columns couldn't be the same as any key column of the index. While it'd be pretty silly to do that, since the included column would be entirely redundant, we've never prohibited redundant index columns before so it's not very consistent to do so here. Moreover, the prohibition was itself badly implemented, so that it failed to reject columns that were effectively identical but not spelled quite alike, as reported by Aditya Toshniwal. (Moreover, it's not hard to imagine that for some non-btree index types, such cases would be non-silly anyhow: the index might use a lossy representation for key columns but be able to support retrieval of the original form of included columns.) Hence, let's just drop the prohibition. In passing, do some copy-editing on the documentation for the included-column feature. Yugo Nagata; documentation and test corrections by me Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link> for details.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Convert oidvector and int2vector into variable-length arrays. This change saves a great deal of space in pg_proc and its primary index, and it eliminates the former requirement that INDEX_MAX_KEYS and FUNC_MAX_ARGS have the same value. INDEX_MAX_KEYS is still embedded in the on-disk representation (because it affects index tuple header size), but FUNC_MAX_ARGS is not. I believe it would now be possible to increase FUNC_MAX_ARGS at little cost, but haven't experimented yet. There are still a lot of vestigial references to FUNC_MAX_ARGS, which I will clean up in a separate pass. However, getting rid of it altogether would require changing the FunctionCallInfoData struct, and I'm not sure I want to buy into that.
2005-03-29 02:17:27 +02:00
</row>
Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LAST per-column options for btree indexes. The planner's support for this is still pretty rudimentary; it does not yet know how to plan mergejoins with nondefault ordering options. The documentation is pretty rudimentary, too. I'll work on improving that stuff later. Note incompatible change from prior behavior: ORDER BY ... USING will now be rejected if the operator is not a less-than or greater-than member of some btree opclass. This prevents less-than-sane behavior if an operator that doesn't actually define a proper sort ordering is selected.
2007-01-09 03:14:16 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Drop the rule against included index columns duplicating key columns. The initial version of the included-index-column feature stated that included columns couldn't be the same as any key column of the index. While it'd be pretty silly to do that, since the included column would be entirely redundant, we've never prohibited redundant index columns before so it's not very consistent to do so here. Moreover, the prohibition was itself badly implemented, so that it failed to reject columns that were effectively identical but not spelled quite alike, as reported by Aditya Toshniwal. (Moreover, it's not hard to imagine that for some non-btree index types, such cases would be non-silly anyhow: the index might use a lossy representation for key columns but be able to support retrieval of the original form of included columns.) Hence, let's just drop the prohibition. In passing, do some copy-editing on the documentation for the included-column feature. Yugo Nagata; documentation and test corrections by me Discussion: https://postgr.es/m/CAM9w-_mhBCys4fQNfaiQKTRrVWtoFrZ-wXmDuE9Nj5y-Y7aDKQ@mail.gmail.com
2018-07-18 20:43:03 +02:00
This is an array of <structfield>indnkeyatts</structfield> values that
Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LAST per-column options for btree indexes. The planner's support for this is still pretty rudimentary; it does not yet know how to plan mergejoins with nondefault ordering options. The documentation is pretty rudimentary, too. I'll work on improving that stuff later. Note incompatible change from prior behavior: ORDER BY ... USING will now be rejected if the operator is not a less-than or greater-than member of some btree opclass. This prevents less-than-sane behavior if an operator that doesn't actually define a proper sort ordering is selected.
2007-01-09 03:14:16 +01:00
store per-column flag bits. The meaning of the bits is defined by
Spell and markup checking
2010-08-17 06:37:21 +02:00
the index's access method.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support ORDER BY ... NULLS FIRST/LAST, and add ASC/DESC/NULLS FIRST/NULLS LAST per-column options for btree indexes. The planner's support for this is still pretty rudimentary; it does not yet know how to plan mergejoins with nondefault ordering options. The documentation is pretty rudimentary, too. I'll work on improving that stuff later. Note incompatible change from prior behavior: ORDER BY ... USING will now be rejected if the operator is not a less-than or greater-than member of some btree opclass. This prevents less-than-sane behavior if an operator that doesn't actually define a proper sort ordering is selected.
2007-01-09 03:14:16 +01:00
</row>
Replace functional-index facility with expressional indexes. Any column of an index can now be a computed expression instead of a simple variable. Restrictions on expressions are the same as for predicates (only immutable functions, no sub-selects). This fixes problems recently introduced with inlining SQL functions, because the inlining transformation is applied to both expression trees so the planner can still match them up. Along the way, improve efficiency of handling index predicates (both predicates and index expressions are now cached by the relcache) and fix 7.3 oversight that didn't record dependencies of predicate expressions.
2003-05-28 18:04:02 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Spell and markup checking
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
entry in <structfield>indkey</structfield>. Null if all index attributes
Spell and markup checking
2010-08-17 06:37:21 +02:00
are simple references.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Spell and markup checking
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-inherits">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_inherits</structname></title>
<indexterm zone="catalog-pg-inherits">
<primary>pg_inherits</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_inherits</structname> records information about
doc: Mention index references in pg_inherits Partitioned indexes are also registered in pg_inherits, but the description of this catalog did not reflect that. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org Backpatch-through: 11
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.)
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_inherits</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Mention index references in pg_inherits Partitioned indexes are also registered in pg_inherits, but the description of this catalog did not reflect that. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org Backpatch-through: 11
2020-07-30 08:48:44 +02:00
The OID of the child table or index
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Mention index references in pg_inherits Partitioned indexes are also registered in pg_inherits, but the description of this catalog did not reflect that. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org Backpatch-through: 11
2020-07-30 08:48:44 +02:00
The OID of the parent table or index
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
If there is more than one direct parent for a child table (multiple
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
inheritance), this number tells the order in which the
Spell and markup checking
2010-08-17 06:37:21 +02:00
inherited columns are to be arranged. The count starts at 1.
doc: Mention index references in pg_inherits Partitioned indexes are also registered in pg_inherits, but the description of this catalog did not reflect that. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org Backpatch-through: 11
2020-07-30 08:48:44 +02:00
</para>
<para>
Fix typos and grammar in docs and comments This fixes several areas of the documentation and some comments in matters of style, grammar, or even format. Author: Justin Pryzby Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2020-12-24 09:05:49 +01:00
Indexes cannot have multiple inheritance, since they can only inherit
doc: Mention index references in pg_inherits Partitioned indexes are also registered in pg_inherits, but the description of this catalog did not reflect that. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87k0ynj35y.fsf@wibble.ilmari.org Backpatch-through: 11
2020-07-30 08:48:44 +02:00
when using declarative partitioning.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY Allow a partition be detached from its partitioned table without blocking concurrent queries, by running in two transactions and only requiring ShareUpdateExclusive in the partitioned table. Because it runs in two transactions, it cannot be used in a transaction block. This is the main reason to use dedicated syntax: so that users can choose to use the original mode if they need it. But also, it doesn't work when a default partition exists (because an exclusive lock would still need to be obtained on it, in order to change its partition constraint.) In case the second transaction is cancelled or a crash occurs, there's ALTER TABLE .. DETACH PARTITION .. FINALIZE, which executes the final steps. The main trick to make this work is the addition of column pg_inherits.inhdetachpending, initially false; can only be set true in the first part of this command. Once that is committed, concurrent transactions that use a PartitionDirectory will include or ignore partitions so marked: in optimizer they are ignored if the row is marked committed for the snapshot; in executor they are always included. As a result, and because of the way PartitionDirectory caches partition descriptors, queries that were planned before the detach will see the rows in the detached partition and queries that are planned after the detach, won't. A CHECK constraint is created that duplicates the partition constraint. This is probably not strictly necessary, and some users will prefer to remove it afterwards, but if the partition is re-attached to a partitioned table, the constraint needn't be rechecked. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200803234854.GA24158@alvherre.pgsql
2021-03-25 22:00:28 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>inhdetachpending</structfield> <type>bool</type>
</para>
<para>
<literal>true</literal> for a partition that is in the process of
being detached; <literal>false</literal> otherwise.
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_init_privs</structname> records information about
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
set by <application>initdb</application> or during a
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
<command>CREATE EXTENSION</command> command.
</para>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Objects which have initial privileges set by <application>initdb</application> will
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_init_privs</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
For a table column, this is the column number (the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>objoid</structfield> and <structfield>classoid</structfield> refer to the
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
table itself). For all other object types, this column is
zero.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
A code defining the type of initial privilege of this object; see text
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
The initial access privileges; see
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
<xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on initdb-created or extension-created objects have been changed from what they were set to at initdb/extension-creation time and handle those changes appropriately. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
</row>
</tbody>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-language">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_language</structname></title>
<indexterm zone="catalog-pg-language">
<primary>pg_language</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
The catalog <structname>pg_language</structname> registers
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
languages in which you can write functions or stored procedures.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
See <xref linkend="sql-createlanguage"/>
and <xref linkend="xplang"/> for more information about language handlers.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_language</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Allow non-superuser database owners to create procedural languages. A DBA is allowed to create a language in his database if it's marked "tmpldbacreate" in pg_pltemplate. The factory default is that this is set for all standard trusted languages, but of course a superuser may adjust the settings. In service of this, add the long-foreseen owner column to pg_language; renaming, dropping, and altering owner of a PL now follow normal ownership rules instead of being superuser-only. Jeremy Drake, with some editorialization by Tom Lane.
2007-03-26 18:58:41 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow non-superuser database owners to create procedural languages. A DBA is allowed to create a language in his database if it's marked "tmpldbacreate" in pg_pltemplate. The factory default is that this is set for all standard trusted languages, but of course a superuser may adjust the settings. In service of this, add the long-foreseen owner column to pg_language; renaming, dropping, and altering owner of a PL now follow normal ownership rules instead of being superuser-only. Jeremy Drake, with some editorialization by Tom Lane.
2007-03-26 18:58:41 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Improvement to CREATE TRIGGER and catalog documentation. Neil Conway
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
replaced by a different mechanism in the future.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Update misleading comment about the use of lanpltrusted ... it is significant regardless of the value of lanispl.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
languages.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
For noninternal languages this references the language
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
language. Zero for internal languages.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Implement the DO statement to support execution of PL code without having to create a function for it. Procedural languages now have an additional entry point, namely a function to execute an inline code block. This seemed a better design than trying to hide the transient-ness of the code from the PL. As of this patch, only plpgsql has an inline handler, but probably people will soon write handlers for the other standard PLs. In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE. Petr Jelinek
2009-09-23 01:43:43 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Implement the DO statement to support execution of PL code without having to create a function for it. Procedural languages now have an additional entry point, namely a function to execute an inline code block. This seemed a better design than trying to hide the transient-ness of the code from the PL. As of this patch, only plpgsql has an inline handler, but probably people will soon write handlers for the other standard PLs. In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE. Petr Jelinek
2009-09-23 01:43:43 +02:00
This references a function that is responsible for executing
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<quote>inline</quote> anonymous code blocks
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
(<xref linkend="sql-do"/> blocks).
Spell and markup checking
2010-08-17 06:37:21 +02:00
Zero if inline blocks are not supported.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Implement the DO statement to support execution of PL code without having to create a function for it. Procedural languages now have an additional entry point, namely a function to execute an inline code block. This seemed a better design than trying to hide the transient-ness of the code from the PL. As of this patch, only plpgsql has an inline handler, but probably people will soon write handlers for the other standard PLs. In passing, remove the long-dead LANCOMPILER option of CREATE LANGUAGE. Petr Jelinek
2009-09-23 01:43:43 +02:00
</row>
This patch updates the CREATE LANGUAGE & pg_language docs for the 7.3 table structure. Dave Page
2002-06-20 17:44:06 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
This patch updates the CREATE LANGUAGE & pg_language docs for the 7.3 table structure. Dave Page
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
are created. Zero if no validator is provided.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
This patch updates the CREATE LANGUAGE & pg_language docs for the 7.3 table structure. Dave Page
2002-06-20 17:44:06 +02:00
</row>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-largeobject">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_largeobject</structname></title>
<indexterm zone="catalog-pg-largeobject">
<primary>pg_largeobject</primary>
</indexterm>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_largeobject</structname> holds the data making up
Improve documentation for pg_largeobject changes. Rewrite the documentation in more idiomatic English, and in the process make it somewhat more succinct. Move the discussion of specific large object privileges out of the "server-side functions" section, where it certainly doesn't belong, and into "implementation features". That might not be exactly right either, but it doesn't seem worth creating a new section for this amount of information. Fix a few spelling and layout problems, too.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
segments or <quote>pages</quote> small enough to be conveniently stored as rows
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
in <structname>pg_largeobject</structname>.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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).
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</para>
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Prior to <productname>PostgreSQL</productname> 9.0, there was no permission structure
Improve documentation for pg_largeobject changes. Rewrite the documentation in more idiomatic English, and in the process make it somewhat more succinct. Move the discussion of specific large object privileges out of the "server-side functions" section, where it certainly doesn't belong, and into "implementation features". That might not be exactly right either, but it doesn't seem worth creating a new section for this amount of information. Fix a few spelling and layout problems, too.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</structname></link>
Improve documentation for pg_largeobject changes. Rewrite the documentation in more idiomatic English, and in the process make it somewhat more succinct. Move the discussion of specific large object privileges out of the "server-side functions" section, where it certainly doesn't belong, and into "implementation features". That might not be exactly right either, but it doesn't seem worth creating a new section for this amount of information. Fix a few spelling and layout problems, too.
2009-12-17 15:36:16 +01:00
to obtain a list of large object OIDs.
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
</para>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_largeobject</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
Actual data stored in the large object.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
This will never be more than <symbol>LOBLKSIZE</symbol> bytes and might be less.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>LOBLKSIZE</literal> bytes even if they are not the last page of the object.
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
Missing regions within a large object read as zeroes.
</para>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
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>
Improve documentation for pg_largeobject changes. Rewrite the documentation in more idiomatic English, and in the process make it somewhat more succinct. Move the discussion of specific large object privileges out of the "server-side functions" section, where it certainly doesn't belong, and into "implementation features". That might not be exactly right either, but it doesn't seem worth creating a new section for this amount of information. Fix a few spelling and layout problems, too.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<link linkend="catalog-pg-largeobject"><structname>pg_largeobject</structname></link>.
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_largeobject_metadata</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add large object access control. A new system catalog pg_largeobject_metadata manages ownership and access privileges of large objects. KaiGai Kohei, reviewed by Jaime Casanova.
2009-12-11 04:34:57 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
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
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
<sect1 id="catalog-pg-namespace">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_namespace</structname></title>
<indexterm zone="catalog-pg-namespace">
<primary>pg_namespace</primary>
</indexterm>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_namespace</structname> stores namespaces.
Add better markup and improve some text here and there.
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
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
conflicts.
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_namespace</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Create the pg_namespace system catalog. Doesn't do much yet, but it's there and CREATE SCHEMA will make entries in it...
2002-03-22 22:34:44 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<sect1 id="catalog-pg-opclass">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_opclass</structname></title>
<indexterm zone="catalog-pg-opclass">
<primary>pg_opclass</primary>
</indexterm>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_opclass</structname> defines
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
index access method operator classes. Each operator class defines
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
semantics for index columns of a particular data type and a particular
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
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
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
as their left-hand input.
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</para>
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
Operator classes are described at length in <xref linkend="xindex"/>.
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_opclass</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</row>
</tbody>
</tgroup>
</table>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
An operator class's <structfield>opcmethod</structfield> must match the
Fix inconsistent markups in catalogs.sgml Some fields related to pg_opclass and pg_opfamily were using incorrect markups, listing them as structname instead of structfield. Author: Fabien Coelho Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2006210903560.859381@pseudo
2020-06-22 06:40:04 +02:00
<structfield>opfmethod</structfield> of its containing operator family.
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
Also, there must be no more than one <structname>pg_opclass</structname>
Fix inconsistent markups in catalogs.sgml Some fields related to pg_opclass and pg_opfamily were using incorrect markups, listing them as structname instead of structfield. Author: Fabien Coelho Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2006210903560.859381@pseudo
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>.
Rewrite xindex.sgml for CREATE OPERATOR CLASS. catalogs.sgml finally contains descriptions of every single system table. Update 'complex' tutorial example too.
2002-07-30 07:24:56 +02:00
</para>
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-operator">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_operator</structname></title>
<indexterm zone="catalog-pg-operator">
<primary>pg_operator</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The catalog <structname>pg_operator</structname> stores information about operators.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
See <xref linkend="sql-createoperator"/>
and <xref linkend="xoper"/> for more information.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_operator</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Operators live in namespaces. CREATE/DROP/COMMENT ON OPERATOR take qualified operator names directly, for example CREATE OPERATOR myschema.+ ( ... ). To qualify an operator name in an expression you need to write OPERATOR(myschema.+) (thanks to Peter for suggesting an escape hatch). I also took advantage of having to reformat pg_operator to fix something that'd been bugging me for a while: mergejoinable operators should have explicit links to the associated cross-data-type comparison operators, rather than hardwiring an assumption that they are named < and >.
2002-04-17 01:08:12 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Operators live in namespaces. CREATE/DROP/COMMENT ON OPERATOR take qualified operator names directly, for example CREATE OPERATOR myschema.+ ( ... ). To qualify an operator name in an expression you need to write OPERATOR(myschema.+) (thanks to Peter for suggesting an escape hatch). I also took advantage of having to reformat pg_operator to fix something that'd been bugging me for a while: mergejoinable operators should have explicit links to the associated cross-data-type comparison operators, rather than hardwiring an assumption that they are named < and >.
2002-04-17 01:08:12 +02:00
The OID of the namespace that contains this operator
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Operators live in namespaces. CREATE/DROP/COMMENT ON OPERATOR take qualified operator names directly, for example CREATE OPERATOR myschema.+ ( ... ). To qualify an operator name in an expression you need to write OPERATOR(myschema.+) (thanks to Peter for suggesting an escape hatch). I also took advantage of having to reformat pg_operator to fix something that'd been bugging me for a while: mergejoinable operators should have explicit links to the associated cross-data-type comparison operators, rather than hardwiring an assumption that they are named < and >.
2002-04-17 01:08:12 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Type of the left operand (zero for a prefix operator)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
(zero for a not-yet-defined <quote>shell</quote> operator)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Commutator of this operator (zero if none)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Negator of this operator (zero if none)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
(zero for a not-yet-defined <quote>shell</quote> operator)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
(zero if none)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
(zero if none)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<quote>compatible</quote>, in a way that is specified by the access method.
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
Operator families are described at length in <xref linkend="xindex"/>.
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_opfamily</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
2006-12-23 01:43:13 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure operator classes to allow improved handling of cross-data-type cases. Operator classes now exist within "operator families". While most families are equivalent to a single class, related classes can be grouped into one family to represent the fact that they are semantically compatible. Cross-type operators are now naturally adjunct parts of a family, without having to wedge them into a particular opclass as we had done originally. This commit restructures the catalogs and cleans up enough of the fallout so that everything still works at least as well as before, but most of the work needed to actually improve the planner's behavior will come later. Also, there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way to create a new family right now is to allow CREATE OPERATOR CLASS to make one by default. I owe some more documentation work, too. But that can all be done in smaller pieces once this infrastructure is in place.
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>
Allow granting SET and ALTER SYSTEM privileges on GUC parameters. This patch allows "PGC_SUSET" parameters to be set by non-superusers if they have been explicitly granted the privilege to do so. The privilege to perform ALTER SYSTEM SET/RESET on a specific parameter can also be granted. Such privileges are cluster-wide, not per database. They are tracked in a new shared catalog, pg_parameter_acl. Granting and revoking these new privileges works as one would expect. One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege --- one could wish that those were handled by a revocable grant to PUBLIC, but they are not, because we couldn't make it robust enough for GUCs defined by extensions. Mark Dilger, reviewed at various times by Andrew Dunstan, Robert Haas, Joshua Brindle, and myself Discussion: https://postgr.es/m/3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com
2022-04-06 19:24:33 +02:00
<sect1 id="catalog-pg-parameter-acl">
<title><structname>pg_parameter_acl</structname></title>
<indexterm zone="catalog-pg-parameter-acl">
<primary>pg_parameter_acl</primary>
</indexterm>
<para>
The catalog <structname>pg_parameter_acl</structname> records configuration
parameters for which privileges have been granted to one or more roles.
No entry is made for parameters that have default privileges.
</para>
<para>
Unlike most system catalogs, <structname>pg_parameter_acl</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_parameter_acl</structname> per cluster, not
one per database.
</para>
<table>
<title><structname>pg_parameter_acl</structname> Columns</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>parname</structfield> <type>text</type>
</para>
<para>
The name of a configuration parameter for which privileges are granted
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>paracl</structfield> <type>aclitem[]</type>
</para>
<para>
Access privileges; see <xref linkend="ddl-priv"/> for details
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_partitioned_table</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Documentation updates for partitioning. Takayuki Tsunakawa Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F965627@G01JPEXMBYT05
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The number of columns in the partition key
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
have a default partition
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
For each column in the partition key, this contains the OID of the
Fix some cases of "the the" split across two lines. Kevin Grittner observed that 2186b608b3cb859fe0ec04015a5c4e4cbf69caed introduced a new occurence of this by copying existing text, and I found a few more cases using grep. Discussion: http://postgr.es/m/CADAecHWfG-K+YvocHCkrXV-ycm+eUOaaUVfYZNOnwf0pSmuQCw@mail.gmail.com
2017-06-06 18:24:44 +02:00
collation to use for partitioning, or zero if the column is not
Clean up partcollation handling for OID 0. Consistent with what we do for indexes, we shouldn't try to record dependencies on collation OID 0 or the default collation OID (which is pinned). Also, the fact that indcollation and partcollation can contain zero OIDs when the data type is not collatable should be documented. Amit Langote, per a complaint from me. Discussion: http://postgr.es/m/CA+Tgmoba5mtPgM3NKfG06vv8na5gGbVOj0h4zvivXQwLw8wXXQ@mail.gmail.com
2017-06-06 17:07:20 +02:00
of a collatable data type.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
entry in <structfield>partattrs</structfield>. Null if all partition key columns
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
are simple references.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
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>
doc: Improve hyphenation consistency
2021-04-21 08:14:43 +02:00
The catalog <structname>pg_policy</structname> stores row-level
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
to be added as a <literal>WITH CHECK</literal> option for queries that attempt to
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
add new records to the table.
</para>
<table>
<title><structname>pg_policy</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
</thead>
<tbody>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
</row>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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:
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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"/>,
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
or <literal>*</literal> for all
</para></entry>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
Add support for restrictive RLS policies We have had support for restrictive RLS policies since 9.5, but they were only available through extensions which use the appropriate hooks. This adds support into the grammer, catalog, psql and pg_dump for restrictive RLS policies, thus reducing the cases where an extension is necessary. In passing, also move away from using "AND"d and "OR"d in comments. As pointed out by Alvaro, it's not really appropriate to attempt to make verbs out of "AND" and "OR", so reword those comments which attempted to. Reviewed By: Jeevan Chalke, Dean Rasheed Discussion: https://postgr.es/m/20160901063404.GY4028@tamriel.snowman.net
2016-12-05 21:50:55 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add support for restrictive RLS policies We have had support for restrictive RLS policies since 9.5, but they were only available through extensions which use the appropriate hooks. This adds support into the grammer, catalog, psql and pg_dump for restrictive RLS policies, thus reducing the cases where an extension is necessary. In passing, also move away from using "AND"d and "OR"d in comments. As pointed out by Alvaro, it's not really appropriate to attempt to make verbs out of "AND" and "OR", so reword those comments which attempted to. Reviewed By: Jeevan Chalke, Dean Rasheed Discussion: https://postgr.es/m/20160901063404.GY4028@tamriel.snowman.net
2016-12-05 21:50:55 +01:00
</row>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The roles to which the policy is applied;
zero means <literal>PUBLIC</literal>
(and normally appears alone in the array)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
</row>
</tbody>
</tgroup>
</table>
<note>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Policies stored in <structname>pg_policy</structname> are applied only when
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>relrowsecurity</structfield> is set for
Clean up some mess in row-security patches. Fix unsafe coding around PG_TRY in RelationBuildRowSecurity: can't change a variable inside PG_TRY and then use it in PG_CATCH without marking it "volatile". In this case though it seems saner to avoid that by doing a single assignment before entering the TRY block. I started out just intending to fix that, but the more I looked at the row-security code the more distressed I got. This patch also fixes incorrect construction of the RowSecurityPolicy cache entries (there was not sufficient care taken to copy pass-by-ref data into the cache memory context) and a whole bunch of sloppiness around the definition and use of pg_policy.polcmd. You can't use nulls in that column because initdb will mark it NOT NULL --- and I see no particular reason why a null entry would be a good idea anyway, so changing initdb's behavior is not the right answer. The internal value of '\0' wouldn't be suitable in a "char" column either, so after a bit of thought I settled on using '*' to represent ALL. Chasing those changes down also revealed that somebody wasn't paying attention to what the underlying values of ACL_UPDATE_CHR etc really were, and there was a great deal of lackadaiscalness in the catalogs.sgml documentation for pg_policy and pg_policies too. This doesn't pretend to be a complete code review for the row-security stuff, it just fixes the things that were in my face while dealing with the bugs in RelationBuildRowSecurity.
2015-01-24 22:16:22 +01:00
their table.
</para>
</note>
</sect1>
Create the pg_pltemplate system catalog to hold template information for procedural languages. This replaces the hard-wired table I had originally proposed as a stopgap solution. For the moment, the initial contents only include languages shipped with the core distribution.
2005-09-08 22:07:42 +02:00
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-proc">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_proc</structname></title>
<indexterm zone="catalog-pg-proc">
<primary>pg_proc</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Add prokind column, replacing proisagg and proiswindow The new column distinguishes normal functions, procedures, aggregates, and window functions. This replaces the existing columns proisagg and proiswindow, and replaces the convention that procedures are indicated by prorettype == 0. Also change prorettype to be VOIDOID for procedures. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
<para>
Add prokind column, replacing proisagg and proiswindow The new column distinguishes normal functions, procedures, aggregates, and window functions. This replaces the existing columns proisagg and proiswindow, and replaces the convention that procedures are indicated by prorettype == 0. Also change prorettype to be VOIDOID for procedures. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz>
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-aggregate"><structfield>pg_aggregate</structfield></link>.
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_proc</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
The OID of the namespace that contains this function
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Add COST and ROWS options to CREATE/ALTER FUNCTION, plus underlying pg_proc columns procost and prorows, to allow simple user adjustment of the estimated cost of a function call, as well as control of the estimated number of rows returned by a set-returning function. We might eventually wish to extend this to allow function-specific estimation routines, but there seems to be consensus that we should try a simple constant estimate first. In particular this provides a relatively simple way to control the order in which different WHERE clauses are applied in a plan node, which is a Good Thing in view of the fact that the recent EquivalenceClass planner rewrite made that much less predictable than before.
2007-01-22 02:35:23 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="guc-cpu-operator-cost"/>); if <structfield>proretset</structfield>,
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
this is cost per row returned
</para></entry>
Add COST and ROWS options to CREATE/ALTER FUNCTION, plus underlying pg_proc columns procost and prorows, to allow simple user adjustment of the estimated cost of a function call, as well as control of the estimated number of rows returned by a set-returning function. We might eventually wish to extend this to allow function-specific estimation routines, but there seems to be consensus that we should try a simple constant estimate first. In particular this provides a relatively simple way to control the order in which different WHERE clauses are applied in a plan node, which is a Good Thing in view of the fact that the recent EquivalenceClass planner rewrite made that much less predictable than before.
2007-01-22 02:35:23 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add COST and ROWS options to CREATE/ALTER FUNCTION, plus underlying pg_proc columns procost and prorows, to allow simple user adjustment of the estimated cost of a function call, as well as control of the estimated number of rows returned by a set-returning function. We might eventually wish to extend this to allow function-specific estimation routines, but there seems to be consensus that we should try a simple constant estimate first. In particular this provides a relatively simple way to control the order in which different WHERE clauses are applied in a plan node, which is a Good Thing in view of the fact that the recent EquivalenceClass planner rewrite made that much less predictable than before.
2007-01-22 02:35:23 +01:00
</row>
Add a "provariadic" column to pg_proc to eliminate the remarkably expensive need to deconstruct proargmodes for each pg_proc entry inspected by FuncnameGetCandidates(). Fixes function lookup performance regression caused by yesterday's variadic-functions patch. In passing, make pg_proc.probin be NULL, rather than a dummy value '-', in cases where it is not actually used for the particular type of function. This should buy back some of the space cost of the extra column.
2008-07-16 18:55:24 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a "provariadic" column to pg_proc to eliminate the remarkably expensive need to deconstruct proargmodes for each pg_proc entry inspected by FuncnameGetCandidates(). Fixes function lookup performance regression caused by yesterday's variadic-functions patch. In passing, make pg_proc.probin be NULL, rather than a dummy value '-', in cases where it is not actually used for the particular type of function. This should buy back some of the space cost of the extra column.
2008-07-16 18:55:24 +02:00
</row>
Add notion of a "transform function" that can simplify function calls. Initially, we use this only to eliminate calls to the varchar() function in cases where the length is not being reduced and, therefore, the function call is equivalent to a RelabelType operation. The most significant effect of this is that we can avoid a table rewrite when changing a varchar(X) column to a varchar(Y) column, where Y > X. Noah Misch, reviewed by me and Alexey Klyukin
2011-06-22 04:15:24 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Planner support function for this function
(see <xref linkend="xfunc-optimization"/>), or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add notion of a "transform function" that can simplify function calls. Initially, we use this only to eliminate calls to the varchar() function in cases where the length is not being reduced and, therefore, the function call is equivalent to a RelabelType operation. The most significant effect of this is that we can avoid a table rewrite when changing a varchar(X) column to a varchar(Y) column, where Y > X. Noah Misch, reviewed by me and Alexey Klyukin
2011-06-22 04:15:24 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a new column proiswindow to pg_proc. It doesn't actually do anything useful yet, but I'm tired of re-merging this aspect of the window functions patch.
2008-12-19 19:25:20 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow LEAKPROOF functions for better performance of security views. We don't normally allow quals to be pushed down into a view created with the security_barrier option, but functions without side effects are an exception: they're OK. This allows much better performance in common cases, such as when using an equality operator (that might even be indexable). There is an outstanding issue here with the CREATE FUNCTION / ALTER FUNCTION syntax: there's no way to use ALTER FUNCTION to unset the leakproof flag. But I'm committing this as-is so that it doesn't have to be rebased again; we can fix up the grammar in a future commit. KaiGai Kohei, with some wordsmithing by me.
2012-02-14 04:20:27 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow LEAKPROOF functions for better performance of security views. We don't normally allow quals to be pushed down into a view created with the security_barrier option, but functions without side effects are an exception: they're OK. This allows much better performance in common cases, such as when using an equality operator (that might even be indexable). There is an outstanding issue here with the CREATE FUNCTION / ALTER FUNCTION syntax: there's no way to use ALTER FUNCTION to unset the leakproof flag. But I'm committing this as-is so that it doesn't have to be rebased again; we can fix up the grammar in a future commit. KaiGai Kohei, with some wordsmithing by me.
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
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
is not leak-proof.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
null inputs.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Restructure representation of aggregate functions so that they have pg_proc entries, per pghackers discussion. This fixes aggregates to live in namespaces, and also simplifies/speeds up lookup in parse_func.c. Also, add a 'proimplicit' flag to pg_proc that controls whether a type coercion function may be invoked implicitly, or only explicitly. The current settings of these flags are more permissive than I would like, but we will need to debate and refine the behavior; for now, I avoided breaking regression tests as much as I could.
2002-04-11 22:00:18 +02:00
</row>
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
It is <literal>i</literal> for <quote>immutable</quote> functions,
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
which always deliver the same result for the same inputs.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
It is <literal>s</literal> for <quote>stable</quote> functions,
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
whose results (for fixed inputs) do not change within a scan.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
for functions with side-effects, so that calls to them cannot get
optimized away.)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Divide functions into three volatility classes (immutable, stable, and volatile), rather than the old cachable/noncachable distinction. This allows indexscan optimizations in many places where we formerly didn't. Also, add a pronamespace column to pg_proc (it doesn't do anything yet, however).
2002-04-05 02:31:36 +02:00
</row>
Determine whether it's safe to attempt a parallel plan for a query. Commit 924bcf4f16d54c55310b28f77686608684734f42 introduced a framework for parallel computation in PostgreSQL that makes most but not all built-in functions safe to execute in parallel mode. In order to have parallel query, we'll need to be able to determine whether that query contains functions (either built-in or user-defined) that cannot be safely executed in parallel mode. This requires those functions to be labeled, so this patch introduces an infrastructure for that. Some functions currently labeled as safe may need to be revised depending on how pending issues related to heavyweight locking under paralllelism are resolved. Parallel plans can't be used except for the case where the query will run to completion. If portal execution were suspended, the parallel mode restrictions would need to remain in effect during that time, but that might make other queries fail. Therefore, this patch introduces a framework that enables consideration of parallel plans only when it is known that the plan will be run to completion. This probably needs some refinement; for example, at bind time, we do not know whether a query run via the extended protocol will be execution to completion or run with a limited fetch count. Having the client indicate its intentions at bind time would constitute a wire protocol break. Some contexts in which parallel mode would be safe are not adjusted by this patch; the default is not to try parallel plans except from call sites that have been updated to say that such plans are OK. This commit doesn't introduce any parallel paths or plans; it just provides a way to determine whether they could potentially be used. I'm committing it on the theory that the remaining parallel sequential scan patches will also get committed to this release, hopefully in the not-too-distant future. Robert Haas and Amit Kapila. Reviewed (in earlier versions) by Noah Misch.
2015-09-16 21:38:47 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Determine whether it's safe to attempt a parallel plan for a query. Commit 924bcf4f16d54c55310b28f77686608684734f42 introduced a framework for parallel computation in PostgreSQL that makes most but not all built-in functions safe to execute in parallel mode. In order to have parallel query, we'll need to be able to determine whether that query contains functions (either built-in or user-defined) that cannot be safely executed in parallel mode. This requires those functions to be labeled, so this patch introduces an infrastructure for that. Some functions currently labeled as safe may need to be revised depending on how pending issues related to heavyweight locking under paralllelism are resolved. Parallel plans can't be used except for the case where the query will run to completion. If portal execution were suspended, the parallel mode restrictions would need to remain in effect during that time, but that might make other queries fail. Therefore, this patch introduces a framework that enables consideration of parallel plans only when it is known that the plan will be run to completion. This probably needs some refinement; for example, at bind time, we do not know whether a query run via the extended protocol will be execution to completion or run with a limited fetch count. Having the client indicate its intentions at bind time would constitute a wire protocol break. Some contexts in which parallel mode would be safe are not adjusted by this patch; the default is not to try parallel plans except from call sites that have been updated to say that such plans are OK. This commit doesn't introduce any parallel paths or plans; it just provides a way to determine whether they could potentially be used. I'm committing it on the theory that the remaining parallel sequential scan patches will also get committed to this release, hopefully in the not-too-distant future. Robert Haas and Amit Kapila. Reviewed (in earlier versions) by Noah Misch.
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Determine whether it's safe to attempt a parallel plan for a query. Commit 924bcf4f16d54c55310b28f77686608684734f42 introduced a framework for parallel computation in PostgreSQL that makes most but not all built-in functions safe to execute in parallel mode. In order to have parallel query, we'll need to be able to determine whether that query contains functions (either built-in or user-defined) that cannot be safely executed in parallel mode. This requires those functions to be labeled, so this patch introduces an infrastructure for that. Some functions currently labeled as safe may need to be revised depending on how pending issues related to heavyweight locking under paralllelism are resolved. Parallel plans can't be used except for the case where the query will run to completion. If portal execution were suspended, the parallel mode restrictions would need to remain in effect during that time, but that might make other queries fail. Therefore, this patch introduces a framework that enables consideration of parallel plans only when it is known that the plan will be run to completion. This probably needs some refinement; for example, at bind time, we do not know whether a query run via the extended protocol will be execution to completion or run with a limited fetch count. Having the client indicate its intentions at bind time would constitute a wire protocol break. Some contexts in which parallel mode would be safe are not adjusted by this patch; the default is not to try parallel plans except from call sites that have been updated to say that such plans are OK. This commit doesn't introduce any parallel paths or plans; it just provides a way to determine whether they could potentially be used. I'm committing it on the theory that the remaining parallel sequential scan patches will also get committed to this release, hopefully in the not-too-distant future. Robert Haas and Amit Kapila. Reviewed (in earlier versions) by Noah Misch.
2015-09-16 21:38:47 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Code review for function default parameters patch. Fix numerous problems as per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
2008-12-18 19:20:35 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: improve documentation of pg_proc.protrftypes. Add a "references" link pointing to pg_type, as we have for other arrays of type OIDs. Wordsmith the explanation a bit. Joel Jacobson, additional editing by me Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com
2021-01-25 17:20:17 +01:00
An array of the data types of the function arguments. This includes
Support "variadic" functions, which can accept a variable number of arguments so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Pavel Stehule
2008-07-16 03:30:23 +02:00
only input arguments (including <literal>INOUT</literal> and
Reconsider the handling of procedure OUT parameters. Commit 2453ea142 redefined pg_proc.proargtypes to include the types of OUT parameters, for procedures only. While that had some advantages for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty disastrous from a number of other perspectives. Notably, since the primary key of pg_proc is name + proargtypes, this made it possible to have multiple procedures with identical names + input arguments and differing output argument types. That would make it impossible to call any one of the procedures by writing just NULL (or "?", or any other data-type-free notation) for the output argument(s). The change also seems likely to cause grave confusion for client applications that examine pg_proc and expect the traditional definition of proargtypes. Hence, revert the definition of proargtypes to what it was, and undo a number of complications that had been added to support that. To support the SQL-spec behavior of DROP PROCEDURE, when there are no argmode markers in the command's parameter list, we perform the lookup both ways (that is, matching against both proargtypes and proallargtypes), succeeding if we get just one unique match. In principle this could result in ambiguous-function failures that would not happen when using only one of the two rules. However, overloading of procedure names is thought to be a pretty rare usage, so this shouldn't cause many problems in practice. Postgres-specific code such as pg_dump can defend against any possibility of such failures by being careful to specify argmodes for all procedure arguments. This also fixes a few other bugs in the area of CALL statements with named parameters, and improves the documentation a little. catversion bump forced because the representation of procedures with OUT arguments changes. Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
<literal>VARIADIC</literal> arguments), and thus represents
the call signature of the function.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add proallargtypes and proargmodes columns to pg_proc, as per my earlier proposal for OUT parameter support. The columns don't actually *do* anything yet, they are just left NULLs. But I thought I'd commit this part separately as a fairly pure example of the tasks needed when adding a column to pg_proc or one of the other core system tables.
2005-03-29 21:44:23 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: improve documentation of pg_proc.protrftypes. Add a "references" link pointing to pg_type, as we have for other arrays of type OIDs. Wordsmith the explanation a bit. Joel Jacobson, additional editing by me Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com
2021-01-25 17:20:17 +01:00
An array of the data types of the function arguments. This includes
Support "variadic" functions, which can accept a variable number of arguments so long as all the trailing arguments are of the same (non-array) type. The function receives them as a single array argument (which is why they have to all be the same type). It might be useful to extend this facility to aggregates, but this patch doesn't do that. This patch imposes a noticeable slowdown on function lookup --- a follow-on patch will fix that by adding a redundant column to pg_proc. Pavel Stehule
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.
Add proallargtypes and proargmodes columns to pg_proc, as per my earlier proposal for OUT parameter support. The columns don't actually *do* anything yet, they are just left NULLs. But I thought I'd commit this part separately as a fairly pure example of the tasks needed when adding a column to pg_proc or one of the other core system tables.
2005-03-29 21:44:23 +02:00
Note that subscripting is 1-based, whereas for historical reasons
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>proargtypes</structfield> is subscripted from 0.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add proallargtypes and proargmodes columns to pg_proc, as per my earlier proposal for OUT parameter support. The columns don't actually *do* anything yet, they are just left NULLs. But I thought I'd commit this part separately as a fairly pure example of the tasks needed when adding a column to pg_proc or one of the other core system tables.
2005-03-29 21:44:23 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: improve documentation of pg_proc.protrftypes. Add a "references" link pointing to pg_type, as we have for other arrays of type OIDs. Wordsmith the explanation a bit. Joel Jacobson, additional editing by me Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com
2021-01-25 17:20:17 +01:00
An array of the modes of the function arguments, encoded as
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<literal>i</literal> for <literal>IN</literal> arguments,
<literal>o</literal> for <literal>OUT</literal> arguments,
<literal>b</literal> for <literal>INOUT</literal> arguments,
<literal>v</literal> for <literal>VARIADIC</literal> arguments,
<literal>t</literal> for <literal>TABLE</literal> arguments.
If all the arguments are <literal>IN</literal> arguments,
this field will be null.
Note that subscripts correspond to positions of
<structfield>proallargtypes</structfield> not <structfield>proargtypes</structfield>.
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Apply the core parts of Dennis Bjorklund's patch to allow function parameters to be declared with names. pg_proc has a column to store names, and CREATE FUNCTION can insert data into it, but that's all as yet. I need to do more work on the pg_dump and plpgsql portions of the patch before committing those, but I thought I'd get the bulky changes in before the tree drifts under me. initdb forced due to pg_proc change.
2004-01-07 00:55:19 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: improve documentation of pg_proc.protrftypes. Add a "references" link pointing to pg_type, as we have for other arrays of type OIDs. Wordsmith the explanation a bit. Joel Jacobson, additional editing by me Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com
2021-01-25 17:20:17 +01:00
An array of the names of the function arguments.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Arguments without a name are set to empty strings in the array.
If none of the arguments have a name, this field will be null.
Note that subscripts correspond to positions of
<structfield>proallargtypes</structfield> not <structfield>proargtypes</structfield>.
</para></entry>
Apply the core parts of Dennis Bjorklund's patch to allow function parameters to be declared with names. pg_proc has a column to store names, and CREATE FUNCTION can insert data into it, but that's all as yet. I need to do more work on the pg_dump and plpgsql portions of the patch before committing those, but I thought I'd get the bulky changes in before the tree drifts under me. initdb forced due to pg_proc change.
2004-01-07 00:55:19 +01:00
</row>
Code review for function default parameters patch. Fix numerous problems as per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
2008-12-18 19:20:35 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Code review for function default parameters patch. Fix numerous problems as per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
2008-12-18 19:20:35 +01:00
Expression trees (in <function>nodeToString()</function> representation)
for default values. This is a list with
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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).
Spell and markup checking
2010-08-17 06:37:21 +02:00
If none of the arguments have defaults, this field will be null.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Code review for function default parameters patch. Fix numerous problems as per recent discussions. In passing this also fixes a couple of bugs in the previous variadic-parameters patch.
2008-12-18 19:20:35 +01:00
</row>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>protrftypes</structfield> <type>oid[]</type>
Doc: improve documentation of pg_proc.protrftypes. Add a "references" link pointing to pg_type, as we have for other arrays of type OIDs. Wordsmith the explanation a bit. Joel Jacobson, additional editing by me Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com
2021-01-25 17:20:17 +01:00
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Doc: improve documentation of pg_proc.protrftypes. Add a "references" link pointing to pg_type, as we have for other arrays of type OIDs. Wordsmith the explanation a bit. Joel Jacobson, additional editing by me Discussion: https://postgr.es/m/d1cc628c-3953-4209-957b-29427acc38c8@www.fastmail.com
2021-01-25 17:20:17 +01:00
An array of the argument/result data type(s) for which to apply
transforms (from the function's <literal>TRANSFORM</literal>
clause). Null if none.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
else, depending on the implementation language/call convention.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
Additional information about how to invoke the function.
Spell and markup checking
2010-08-17 06:37:21 +02:00
Again, the interpretation is language-specific.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
SQL-standard function body This adds support for writing CREATE FUNCTION and CREATE PROCEDURE statements for language SQL with a function body that conforms to the SQL standard and is portable to other implementations. Instead of the PostgreSQL-specific AS $$ string literal $$ syntax, this allows writing out the SQL statements making up the body unquoted, either as a single statement: CREATE FUNCTION add(a integer, b integer) RETURNS integer LANGUAGE SQL RETURN a + b; or as a block CREATE PROCEDURE insert_data(a integer, b integer) LANGUAGE SQL BEGIN ATOMIC INSERT INTO tbl VALUES (a); INSERT INTO tbl VALUES (b); END; The function body is parsed at function definition time and stored as expression nodes in a new pg_proc column prosqlbody. So at run time, no further parsing is required. However, this form does not support polymorphic arguments, because there is no more parse analysis done at call time. Dependencies between the function and the objects it uses are fully tracked. A new RETURN statement is introduced. This can only be used inside function bodies. Internally, it is treated much like a SELECT statement. psql needs some new intelligence to keep track of function body boundaries so that it doesn't send off statements when it sees semicolons that are inside a function body. Tested-by: Jaime Casanova <jcasanov@systemguards.com.ec> Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com
2021-04-07 21:30:08 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prosqlbody</structfield> <type>pg_node_tree</type>
</para>
<para>
Undo decision to allow pg_proc.prosrc to be NULL. Commit e717a9a18 changed the longstanding rule that prosrc is NOT NULL because when a SQL-language function is written in SQL-standard style, we don't currently have anything useful to put there. This seems a poor decision though, as it could easily have negative impacts on external PLs (opening them to crashes they didn't use to have, for instance). SQL-function-related code can just as easily test "is prosqlbody not null" as "is prosrc null", so there's no real gain there either. Hence, revert the NOT NULL marking removal and adjust related logic. For now, we just put an empty string into prosrc for SQL-standard functions. Maybe we'll have a better idea later, although the history of things like pg_attrdef.adsrc suggests that it's not easy to maintain a string equivalent of a node tree. This also adds an assertion that queryDesc->sourceText != NULL to standard_ExecutorStart. We'd been silently relying on that for awhile, so let's make it less silent. Also fix some overlooked documentation and test cases. Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us
2021-04-15 23:17:20 +02:00
Pre-parsed SQL function body. This is used for SQL-language
functions when the body is given in SQL-standard notation
rather than as a string literal. It's null in other cases.
SQL-standard function body This adds support for writing CREATE FUNCTION and CREATE PROCEDURE statements for language SQL with a function body that conforms to the SQL standard and is portable to other implementations. Instead of the PostgreSQL-specific AS $$ string literal $$ syntax, this allows writing out the SQL statements making up the body unquoted, either as a single statement: CREATE FUNCTION add(a integer, b integer) RETURNS integer LANGUAGE SQL RETURN a + b; or as a block CREATE PROCEDURE insert_data(a integer, b integer) LANGUAGE SQL BEGIN ATOMIC INSERT INTO tbl VALUES (a); INSERT INTO tbl VALUES (b); END; The function body is parsed at function definition time and stored as expression nodes in a new pg_proc column prosqlbody. So at run time, no further parsing is required. However, this form does not support polymorphic arguments, because there is no more parse analysis done at call time. Dependencies between the function and the objects it uses are fully tracked. A new RETURN statement is introduced. This can only be used inside function bodies. Internally, it is treated much like a SELECT statement. psql needs some new intelligence to keep track of function body boundaries so that it doesn't send off statements when it sees semicolons that are inside a function body. Tested-by: Jaime Casanova <jcasanov@systemguards.com.ec> Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/1c11f1eb-f00c-43b7-799d-2d44132c02d7@2ndquadrant.com
2021-04-07 21:30:08 +02:00
</para></entry>
</row>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
Implement function-local GUC parameter settings, as per recent discussion. There are still some loose ends: I didn't do anything about the SET FROM CURRENT idea yet, and it's not real clear whether we are happy with the interaction of SET LOCAL with function-local settings. The documentation is a bit spartan, too.
2007-09-03 02:39:26 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Implement function-local GUC parameter settings, as per recent discussion. There are still some loose ends: I didn't do anything about the SET FROM CURRENT idea yet, and it's not real clear whether we are happy with the interaction of SET LOCAL with function-local settings. The documentation is a bit spartan, too.
2007-09-03 02:39:26 +02:00
</row>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</tbody>
</tgroup>
</table>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<para>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
For compiled functions, both built-in and dynamically loaded,
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<structfield>prosrc</structfield> contains the function's C-language
Undo decision to allow pg_proc.prosrc to be NULL. Commit e717a9a18 changed the longstanding rule that prosrc is NOT NULL because when a SQL-language function is written in SQL-standard style, we don't currently have anything useful to put there. This seems a poor decision though, as it could easily have negative impacts on external PLs (opening them to crashes they didn't use to have, for instance). SQL-function-related code can just as easily test "is prosqlbody not null" as "is prosrc null", so there's no real gain there either. Hence, revert the NOT NULL marking removal and adjust related logic. For now, we just put an empty string into prosrc for SQL-standard functions. Maybe we'll have a better idea later, although the history of things like pg_attrdef.adsrc suggests that it's not easy to maintain a string equivalent of a node tree. This also adds an assertion that queryDesc->sourceText != NULL to standard_ExecutorStart. We'd been silently relying on that for awhile, so let's make it less silent. Also fix some overlooked documentation and test cases. Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us
2021-04-15 23:17:20 +02:00
name (link symbol).
For SQL-language functions, <structfield>prosrc</structfield> contains
the function's source text if that is specified as a string literal;
but if the function body is specified in SQL-standard style,
<structfield>prosrc</structfield> is unused (typically it's an empty
string) and <structfield>prosqlbody</structfield> contains the
pre-parsed definition.
For all other currently-known language types,
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<structfield>prosrc</structfield> contains the function's source
Undo decision to allow pg_proc.prosrc to be NULL. Commit e717a9a18 changed the longstanding rule that prosrc is NOT NULL because when a SQL-language function is written in SQL-standard style, we don't currently have anything useful to put there. This seems a poor decision though, as it could easily have negative impacts on external PLs (opening them to crashes they didn't use to have, for instance). SQL-function-related code can just as easily test "is prosqlbody not null" as "is prosrc null", so there's no real gain there either. Hence, revert the NOT NULL marking removal and adjust related logic. For now, we just put an empty string into prosrc for SQL-standard functions. Maybe we'll have a better idea later, although the history of things like pg_attrdef.adsrc suggests that it's not easy to maintain a string equivalent of a node tree. This also adds an assertion that queryDesc->sourceText != NULL to standard_ExecutorStart. We'd been silently relying on that for awhile, so let's make it less silent. Also fix some overlooked documentation and test cases. Discussion: https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us
2021-04-15 23:17:20 +02:00
text. <structfield>probin</structfield> is null except for
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
dynamically-loaded C functions, for which it gives the name of the
shared library file containing the function.
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</para>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="logical-replication-publication"/>.
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</para>
<table>
<title><structname>pg_publication</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
in the database, including any that will be created in the future.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-insert"/> operations are replicated for
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-update"/> operations are replicated for
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-delete"/> operations are replicated for
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
Logical replication support for TRUNCATE Update the built-in logical replication system to make use of the previously added logical decoding for TRUNCATE support. Add the required truncate callback to pgoutput and a new logical replication protocol message. Publications get a new attribute to determine whether to replicate truncate actions. When updating a publication via pg_dump from an older version, this is not set, thus preserving the previous behavior. Author: Simon Riggs <simon@2ndquadrant.com> Author: Marco Nenciarini <marco.nenciarini@2ndquadrant.it> Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Petr Jelinek <petr.jelinek@2ndquadrant.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
2018-04-07 17:24:53 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
If true, <xref linkend="sql-truncate"/> operations are replicated for
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
tables in the publication.
</para></entry>
Logical replication support for TRUNCATE Update the built-in logical replication system to make use of the previously added logical decoding for TRUNCATE support. Add the required truncate callback to pgoutput and a new logical replication protocol message. Publications get a new attribute to determine whether to replicate truncate actions. When updating a publication via pg_dump from an older version, this is not set, thus preserving the previous behavior. Author: Simon Riggs <simon@2ndquadrant.com> Author: Marco Nenciarini <marco.nenciarini@2ndquadrant.it> Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Petr Jelinek <petr.jelinek@2ndquadrant.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
2018-04-07 17:24:53 +02:00
</row>
Allow publishing partition changes via ancestors To control whether partition changes are replicated using their own identity and schema or an ancestor's, add a new parameter that can be set per publication named 'publish_via_partition_root'. This allows replicating a partitioned table into a different partition structure on the subscriber. Author: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Petr Jelinek <petr@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com
2020-04-08 09:59:27 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Allow publishing partition changes via ancestors To control whether partition changes are replicated using their own identity and schema or an ancestor's, add a new parameter that can be set per publication named 'publish_via_partition_root'. This allows replicating a partitioned table into a different partition structure on the subscriber. Author: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Petr Jelinek <petr@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com
2020-04-08 09:59:27 +02:00
identity and schema of its topmost partitioned ancestor mentioned in the
publication instead of its own.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Allow publishing partition changes via ancestors To control whether partition changes are replicated using their own identity and schema or an ancestor's, add a new parameter that can be set per publication named 'publish_via_partition_root'. This allows replicating a partitioned table into a different partition structure on the subscriber. Author: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com> Reviewed-by: Petr Jelinek <petr@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com
2020-04-08 09:59:27 +02:00
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
Allow publishing the tables of schema. A new option "FOR ALL TABLES IN SCHEMA" in Create/Alter Publication allows one or more schemas to be specified, whose tables are selected by the publisher for sending the data to the subscriber. The new syntax allows specifying both the tables and schemas. For example: CREATE PUBLICATION pub1 FOR TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2; OR ALTER PUBLICATION pub1 ADD TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2; A new system table "pg_publication_namespace" has been added, to maintain the schemas that the user wants to publish through the publication. Modified the output plugin (pgoutput) to publish the changes if the relation is part of schema publication. Updates pg_dump to identify and dump schema publications. Updates the \d family of commands to display schema publications and \dRp+ variant will now display associated schemas if any. Author: Vignesh C, Hou Zhijie, Amit Kapila Syntax-Suggested-by: Tom Lane, Alvaro Herrera Reviewed-by: Greg Nancarrow, Masahiko Sawada, Hou Zhijie, Amit Kapila, Haiying Tang, Ajin Cherian, Rahila Syed, Bharath Rupireddy, Mark Dilger Tested-by: Haiying Tang Discussion: https://www.postgresql.org/message-id/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ@mail.gmail.com
2021-10-27 04:14:52 +02:00
<sect1 id="catalog-pg-publication-namespace">
<title><structname>pg_publication_namespace</structname></title>
<indexterm zone="catalog-pg-publication-namespace">
<primary>pg_publication_namespace</primary>
</indexterm>
<para>
The catalog <structname>pg_publication_namespace</structname> contains the
mapping between schemas and publications in the database. This is a
many-to-many mapping.
</para>
<table>
<title><structname>pg_publication_namespace</structname> Columns</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>oid</structfield> <type>oid</type>
</para>
<para>
Row identifier
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pnpubid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-publication"><structname>pg_publication</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to publication
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pnnspid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Reference to schema
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<sect1 id="catalog-pg-publication-rel">
<title><structname>pg_publication_rel</structname></title>
<indexterm zone="catalog-pg-publication-rel">
<primary>pg_publication_rel</primary>
</indexterm>
<para>
The catalog <structname>pg_publication_rel</structname> contains the
mapping between relations and publications in the database. This is a
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
many-to-many mapping. See also <xref linkend="view-pg-publication-tables"/>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
</thead>
<tbody>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
Allow specifying row filters for logical replication of tables. This feature adds row filtering for publication tables. When a publication is defined or modified, an optional WHERE clause can be specified. Rows that don't satisfy this WHERE clause will be filtered out. This allows a set of tables to be partially replicated. The row filter is per table. A new row filter can be added simply by specifying a WHERE clause after the table name. The WHERE clause must be enclosed by parentheses. The row filter WHERE clause for a table added to a publication that publishes UPDATE and/or DELETE operations must contain only columns that are covered by REPLICA IDENTITY. The row filter WHERE clause for a table added to a publication that publishes INSERT can use any column. If the row filter evaluates to NULL, it is regarded as "false". The WHERE clause only allows simple expressions that don't have user-defined functions, user-defined operators, user-defined types, user-defined collations, non-immutable built-in functions, or references to system columns. These restrictions could be addressed in the future. If you choose to do the initial table synchronization, only data that satisfies the row filters is copied to the subscriber. If the subscription has several publications in which a table has been published with different WHERE clauses, rows that satisfy ANY of the expressions will be copied. If a subscriber is a pre-15 version, the initial table synchronization won't use row filters even if they are defined in the publisher. The row filters are applied before publishing the changes. If the subscription has several publications in which the same table has been published with different filters (for the same publish operation), those expressions get OR'ed together so that rows satisfying any of the expressions will be replicated. This means all the other filters become redundant if (a) one of the publications have no filter at all, (b) one of the publications was created using FOR ALL TABLES, (c) one of the publications was created using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema. If your publication contains a partitioned table, the publication parameter publish_via_partition_root determines if it uses the partition's row filter (if the parameter is false, the default) or the root partitioned table's row filter. Psql commands \dRp+ and \d <table-name> will display any row filters. Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prqual</structfield> <type>pg_node_tree</type>
</para>
<para>Expression tree (in <function>nodeToString()</function>
representation) for the relation's publication qualifying condition. Null
if there is no publication qualifying condition.</para></entry>
</row>
Move prattrs to the pg_publication_rel section in docs Commit 923def9a53 documented the prattrs to the pg_publication_namespace catalog, probably due to a rebase mistake. Move it to the section for the pg_publication_rel catalog. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/PH7PR84MB18850A74D275F39762059E6CEE1B9@PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM
2022-03-26 19:06:10 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>prattrs</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
This is an array of values that indicates which table columns are
part of the publication. For example, a value of <literal>1 3</literal>
would mean that the first and the third table columns are published.
A null value indicates that all columns are published.
</para></entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
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>
Further review of range-types patch. Lots of documentation cleanup today, and still more type_sanity tests.
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>.
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_range</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
Multirange datatypes Multiranges are basically sorted arrays of non-overlapping ranges with set-theoretic operations defined over them. Since v14, each range type automatically gets a corresponding multirange datatype. There are both manual and automatic mechanisms for naming multirange types. Once can specify multirange type name using multirange_type_name attribute in CREATE TYPE.  Otherwise, a multirange type name is generated automatically. If the range type name contains "range" then we change that to "multirange". Otherwise, we add "_multirange" to the end. Implementation of multiranges comes with a space-efficient internal representation format, which evades extra paddings and duplicated storage of oids.  Altogether this format allows fetching a particular range by its index in O(n). Statistic gathering and selectivity estimation are implemented for multiranges. For this purpose, stored multirange is approximated as union range without gaps. This field will likely need improvements in the future. Catversion is bumped. Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0 Author: Paul Jungwirth, revised by me Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>rngmultitypid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-type"><structname>pg_type</structname></link>.<structfield>oid</structfield>)
</para>
<para>
OID of the multirange type for this range type
</para></entry>
</row>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
OID of the collation used for range comparisons, or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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,
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
values as <type>double precision</type>, or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</row>
</tbody>
</tgroup>
</table>
Further review of range-types patch. Lots of documentation cleanup today, and still more type_sanity tests.
2011-11-19 00:23:55 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>rngsubopc</structfield> (plus <structfield>rngcollation</structfield>, if the
Further review of range-types patch. Lots of documentation cleanup today, and still more type_sanity tests.
2011-11-19 00:23:55 +01:00
element type is collatable) determines the sort ordering used by the range
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Further review of range-types patch. Lots of documentation cleanup today, and still more type_sanity tests.
2011-11-19 00:23:55 +01:00
improve performance of GiST indexes on the range type.
</para>
Support range data types. Selectivity estimation functions are missing for some range type operators, which is a TODO. Jeff Davis
2011-11-03 12:16:28 +01:00
</sect1>
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
see <xref linkend="replication-origins"/>.
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
2016-05-05 18:33:12 +02:00
</para>
Assorted minor doc/comment fixes. Identify pg_replication_origin as a shared catalog in catalogs.sgml, using the same boilerplate wording used for most other shared catalogs (and tweak another place where someone had randomly deviated from that boilerplate). Make an example in mmgr/README more consistent with surrounding text. Update an obsolete cross-reference in a comment in storage/block.h. Zhuo Ql Discussion: https://postgr.es/m/44296255.1819230.1524889719001@mail.yahoo.com
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>
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
2016-05-05 18:33:12 +02:00
<table>
<title><structname>pg_replication_origin</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
2016-05-05 18:33:12 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
2016-05-05 18:33:12 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
2016-05-05 18:33:12 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Fix ordering/categorization of some recently-added system views. Somebody added pg_replication_origin, pg_replication_origin_status and pg_replication_slots to catalogs.sgml without a whole lot of concern for either alphabetical order or the difference between a table and a view. Clean up the mess. Back-patch to 9.5, not so much because this is critical as because if I don't it will result in a cross-branch divergence in release-9.5.sgml, which would be a maintenance hazard.
2016-05-05 18:33:12 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-rewrite">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_rewrite</structname></title>
<indexterm zone="catalog-pg-rewrite">
<primary>pg_rewrite</primary>
</indexterm>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_rewrite</structname> stores rewrite rules for tables and views.
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_rewrite</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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"/>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
</row>
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
Controls in which <xref linkend="guc-session-replication-role"/> modes
Remove tabs in SGML files.
2007-03-22 16:46:56 +01:00
the rule fires.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Changes pg_trigger and extend pg_rewrite in order to allow triggers and rules to be defined with different, per session controllable, behaviors for replication purposes. This will allow replication systems like Slony-I and, as has been stated on pgsql-hackers, other products to control the firing mechanism of triggers and rewrite rules without modifying the system catalog directly. The firing mechanisms are controlled by a new superuser-only GUC variable, session_replication_role, together with a change to pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both columns are a single char data type now (tgenabled was a bool before). The possible values in these attributes are: 'O' - Trigger/Rule fires when session_replication_role is "origin" (default) or "local". This is the default behavior. 'D' - Trigger/Rule is disabled and fires never 'A' - Trigger/Rule fires always regardless of the setting of session_replication_role 'R' - Trigger/Rule fires when session_replication_role is "replica" The GUC variable can only be changed as long as the system does not have any cached query plans. This will prevent changing the session role and accidentally executing stored procedures or functions that have plans cached that expand to the wrong query set due to differences in the rule firing semantics. The SQL syntax for changing a triggers/rules firing semantics is ALTER TABLE <tabname> <when> TRIGGER|RULE <name>; <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE psql's \d command as well as pg_dump are extended in a backward compatible fashion. Jan
2007-03-20 00:38:32 +01:00
</row>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Query tree (in the form of a
<function>nodeToString()</function> representation) for the
rule's action
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
</tbody>
</tgroup>
</table>
<note>
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>pg_class.relhasrules</literal>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
must be true if a table has any rules in this catalog.
</para>
</note>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
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
Minor improvement to pg_seclabel documentation. This is a bit more consistent with the way pg_description is documented, and also include a useful cross-link.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
way to view security labels, see <xref linkend="view-pg-seclabels"/>.
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</para>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
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>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
<table>
<title><structname>pg_seclabel</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
For a security label on a table column, this is the column number (the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>objoid</structfield> and <structfield>classoid</structfield> refer to
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
the table itself). For all other object types, this column is
zero.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add a SECURITY LABEL command. This is intended as infrastructure to support integration with label-based mandatory access control systems such as SE-Linux. Further changes (mostly hooks) will be needed, but this is a big chunk of it. KaiGai Kohei and Robert Haas
2010-09-28 02:55:27 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
the schema, is in
<link linkend="catalog-pg-class"><structname>pg_class</structname></link>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_sequence</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
Reorder pg_sequence columns to avoid alignment issue On AIX, doubles are aligned at 4 bytes, but int64 is aligned at 8 bytes. Our code assumes that doubles have alignment that can also be applied to int64, but that fails in this case. One effect is that heap_form_tuple() writes tuples in a different layout than Form_pg_sequence expects. Rather than rewrite the whole alignment code, work around the issue by reordering the columns in pg_sequence so that the first int64 column naturally comes out at an 8-byte boundary.
2016-12-21 18:00:00 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Reorder pg_sequence columns to avoid alignment issue On AIX, doubles are aligned at 4 bytes, but int64 is aligned at 8 bytes. Our code assumes that doubles have alignment that can also be applied to int64, but that fails in this case. One effect is that heap_form_tuple() writes tuples in a different layout than Form_pg_sequence expects. Rather than rewrite the whole alignment code, work around the issue by reordering the columns in pg_sequence so that the first int64 column naturally comes out at an 8-byte boundary.
2016-12-21 18:00:00 +01:00
</row>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</row>
Add CREATE SEQUENCE AS <data type> clause This stores a data type, required to be an integer type, with the sequence. The sequences min and max values default to the range supported by the type, and they cannot be set to values exceeding that range. The internal implementation of the sequence is not affected. Change the serial types to create sequences of the appropriate type. This makes sure that the min and max values of the sequence for a serial column match the range of values supported by the table column. So the sequence can no longer overflow the table column. This also makes monitoring for sequence exhaustion/wraparound easier, which currently requires various contortions to cross-reference the sequences with the table columns they are used with. This commit also effectively reverts the pg_sequence column reordering in f3b421da5f4addc95812b9db05a24972b8fd9739, because the new seqtypid column allows us to fill the hole in the struct and create a more natural overall column ordering. Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-02-10 21:12:32 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add CREATE SEQUENCE AS <data type> clause This stores a data type, required to be an integer type, with the sequence. The sequences min and max values default to the range supported by the type, and they cannot be set to values exceeding that range. The internal implementation of the sequence is not affected. Change the serial types to create sequences of the appropriate type. This makes sure that the min and max values of the sequence for a serial column match the range of values supported by the table column. So the sequence can no longer overflow the table column. This also makes monitoring for sequence exhaustion/wraparound easier, which currently requires various contortions to cross-reference the sequences with the table columns they are used with. This commit also effectively reverts the pg_sequence column reordering in f3b421da5f4addc95812b9db05a24972b8fd9739, because the new seqtypid column allows us to fill the hole in the struct and create a more natural overall column ordering. Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2017-02-10 21:12:32 +01:00
</row>
Add pg_sequence system catalog Move sequence metadata (start, increment, etc.) into a proper system catalog instead of storing it in the sequence heap object. This separates the metadata from the sequence data. Sequence metadata is now operated on transactionally by DDL commands, whereas previously rollbacks of sequence-related DDL commands would be ignored. Reviewed-by: Andreas Karlsson <andreas@proxel.se>
2016-12-20 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_shdepend</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace explicit PIN entries in pg_depend with an OID range test. As of v14, pg_depend contains almost 7000 "pin" entries recording the OIDs of built-in objects. This is a fair amount of bloat for every database, and it adds time to pg_depend lookups as well as initdb. We can get rid of all of those entries in favor of an OID range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned". (template1 and the public schema are exceptions. Those exceptions are now wired into IsPinnedObject() instead of initdb's code for filling pg_depend, but it's the same amount of cruft either way.) The contents of pg_shdepend are modified likewise. Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
2021-07-15 17:41:47 +02:00
The OID of the system catalog the dependent object is in
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Replace explicit PIN entries in pg_depend with an OID range test. As of v14, pg_depend contains almost 7000 "pin" entries recording the OIDs of built-in objects. This is a fair amount of bloat for every database, and it adds time to pg_depend lookups as well as initdb. We can get rid of all of those entries in favor of an OID range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned". (template1 and the public schema are exceptions. Those exceptions are now wired into IsPinnedObject() instead of initdb's code for filling pg_depend, but it's the same amount of cruft either way.) The contents of pg_shdepend are modified likewise. Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
2021-07-15 17:41:47 +02:00
The OID of the specific dependent object
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</row>
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
For a table column, this is the column number (the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>objid</structfield> and <structfield>classid</structfield> refer to the
Spell and markup checking
2010-08-17 06:37:21 +02:00
table itself). For all other object types, this column is zero.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support column-level privileges, as required by SQL standard. Stephen Frost, with help from KaiGai Kohei and others
2009-01-22 21:16:10 +01:00
</row>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Change the parameter_types column of the pg_prepared_statements to be an array of regtype, rather than an array of OIDs. This is likely to be more useful to user, and the type OID can easily be obtained by casting a regtype value to OID. Per suggestion from Tom. Update the documentation and regression tests, and bump the catversion.
2006-01-16 19:15:31 +01:00
A code defining the specific semantics of this dependency relationship; see text
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
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
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
object. However, there are several subflavors identified by
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>deptype</structfield>:
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
<variablelist>
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_OWNER</symbol> (<literal>o</literal>)</term>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_ACL</symbol> (<literal>a</literal>)</term>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
dependent object. (A <symbol>SHARED_DEPENDENCY_ACL</symbol> entry is
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
not made for the owner of the object, since the owner will have
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
a <symbol>SHARED_DEPENDENCY_OWNER</symbol> entry anyway.)
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</para>
</listitem>
</varlistentry>
Create a pg_shdepend entry for each role in TO clause of policies. CreatePolicy() and AlterPolicy() omit to create a pg_shdepend entry for each role in the TO clause. Fix this by creating a new shared dependency type called SHARED_DEPENDENCY_POLICY and assigning it to each role. Reported by Noah Misch. Patch by me, reviewed by Alvaro Herrera. Back-patch to 9.5 where RLS was introduced.
2015-07-29 01:01:53 +02:00
<varlistentry>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<term><symbol>SHARED_DEPENDENCY_POLICY</symbol> (<literal>r</literal>)</term>
Create a pg_shdepend entry for each role in TO clause of policies. CreatePolicy() and AlterPolicy() omit to create a pg_shdepend entry for each role in the TO clause. Fix this by creating a new shared dependency type called SHARED_DEPENDENCY_POLICY and assigning it to each role. Reported by Noah Misch. Patch by me, reviewed by Alvaro Herrera. Back-patch to 9.5 where RLS was introduced.
2015-07-29 01:01:53 +02:00
<listitem>
<para>
The referenced object (which must be a role) is mentioned as the
target of a dependent policy object.
</para>
</listitem>
</varlistentry>
Prevent drop of tablespaces used by partitioned relations When a tablespace is used in a partitioned relation (per commits ca4103025dfe in pg12 for tables and 33e6c34c3267 in pg11 for indexes), it is possible to drop the tablespace, potentially causing various problems. One such was reported in bug #16577, where a rewriting ALTER TABLE causes a server crash. Protect against this by using pg_shdepend to keep track of tablespaces when used for relations that don't keep physical files; we now abort a tablespace if we see that the tablespace is referenced from any partitioned relations. Backpatch this to 11, where this problem has been latent all along. We don't try to create pg_shdepend entries for existing partitioned indexes/tables, but any ones that are modified going forward will be protected. Note slight behavior change: when trying to drop a tablespace that contains both regular tables as well as partitioned ones, you'd previously get ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE and now you'll get ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST. Arguably, the latter is more correct. It is possible to add protecting pg_shdepend entries for existing tables/indexes, by doing ALTER TABLE ONLY some_partitioned_table SET TABLESPACE pg_default; ALTER TABLE ONLY some_partitioned_table SET TABLESPACE original_tablespace; for each partitioned table/index that is not in the database default tablespace. Because these partitioned objects do not have storage, no file needs to be actually moved, so it shouldn't take more time than what's required to acquire locks. This query can be used to search for such relations: SELECT ... FROM pg_class WHERE relkind IN ('p', 'I') AND reltablespace <> 0 Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/16577-881633a9f9894fd5@postgresql.org Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Michael Paquier <michael@paquier.xyz>
2021-01-14 19:32:14 +01:00
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_TABLESPACE</symbol> (<literal>t</literal>)</term>
<listitem>
<para>
The referenced object (which must be a tablespace) is mentioned as
the tablespace for a relation that doesn't have storage.
</para>
</listitem>
</varlistentry>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</variablelist>
Update documentation on may/can/might: Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Other dependency flavors might be needed in future. Note in particular
Prevent drop of tablespaces used by partitioned relations When a tablespace is used in a partitioned relation (per commits ca4103025dfe in pg12 for tables and 33e6c34c3267 in pg11 for indexes), it is possible to drop the tablespace, potentially causing various problems. One such was reported in bug #16577, where a rewriting ALTER TABLE causes a server crash. Protect against this by using pg_shdepend to keep track of tablespaces when used for relations that don't keep physical files; we now abort a tablespace if we see that the tablespace is referenced from any partitioned relations. Backpatch this to 11, where this problem has been latent all along. We don't try to create pg_shdepend entries for existing partitioned indexes/tables, but any ones that are modified going forward will be protected. Note slight behavior change: when trying to drop a tablespace that contains both regular tables as well as partitioned ones, you'd previously get ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE and now you'll get ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST. Arguably, the latter is more correct. It is possible to add protecting pg_shdepend entries for existing tables/indexes, by doing ALTER TABLE ONLY some_partitioned_table SET TABLESPACE pg_default; ALTER TABLE ONLY some_partitioned_table SET TABLESPACE original_tablespace; for each partitioned table/index that is not in the database default tablespace. Because these partitioned objects do not have storage, no file needs to be actually moved, so it shouldn't take more time than what's required to acquire locks. This query can be used to search for such relations: SELECT ... FROM pg_class WHERE relkind IN ('p', 'I') AND reltablespace <> 0 Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/16577-881633a9f9894fd5@postgresql.org Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Michael Paquier <michael@paquier.xyz>
2021-01-14 19:32:14 +01:00
that the current definition only supports roles and tablespaces as referenced
objects.
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</para>
Replace explicit PIN entries in pg_depend with an OID range test. As of v14, pg_depend contains almost 7000 "pin" entries recording the OIDs of built-in objects. This is a fair amount of bloat for every database, and it adds time to pg_depend lookups as well as initdb. We can get rid of all of those entries in favor of an OID range check, i.e. "OIDs below FirstUnpinnedObjectId are pinned". (template1 and the public schema are exceptions. Those exceptions are now wired into IsPinnedObject() instead of initdb's code for filling pg_depend, but it's the same amount of cruft either way.) The contents of pg_shdepend are modified likewise. Discussion: https://postgr.es/m/3737988.1618451008@sss.pgh.pa.us
2021-07-15 17:41:47 +02:00
<para>
As in the <structname>pg_depend</structname> catalog, most objects
created during <application>initdb</application> are
considered <quote>pinned</quote>. No entries are made
in <structname>pg_shdepend</structname> that would have a pinned
object as either referenced or dependent object.
</para>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
</sect1>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
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
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
2006-11-12 07:25:37 +01:00
<application>psql</application>'s <literal>\d</literal> commands.
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_shdescription</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
2006-02-12 04:22:21 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
2006-02-12 04:22:21 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
2006-02-12 04:22:21 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
2006-02-12 04:22:21 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
I've created a new shared catalog table pg_shdescription to store comments on cluster global objects like databases, tablespaces, and roles. It touches a lot of places, but not much in the way of big changes. The only design decision I made was to duplicate the query and manipulation functions rather than to try and have them handle both shared and local comments. I believe this is simpler for the code and not an issue for callers because they know what type of object they are dealing with. This has resulted in a shobj_description function analagous to obj_description and backend functions [Create/Delete]SharedComments mirroring the existing [Create/Delete]Comments functions. pg_shdescription.h goes into src/include/catalog/ Kris Jurka
2006-02-12 04:22:21 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
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
Assorted spelling corrections. Thom Brown
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
way to view security labels, see <xref linkend="view-pg-seclabels"/>.
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support SECURITY LABEL on databases, tablespaces, and roles. This requires a new shared catalog, pg_shseclabel. Along the way, fix the security_label regression tests so that they don't monkey with the labels of any pre-existing objects. This is unlikely to matter in practice, since only the label for the "dummy" provider was being manipulated. But this way still seems cleaner. KaiGai Kohei, with fairly extensive hacking by me.
2011-07-20 19:18:24 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Track dependencies on shared objects (which is to say, roles; we already have adequate mechanisms for tracking the contents of databases and tablespaces). This solves the longstanding problem that you can drop a user who still owns objects and/or has access permissions. Alvaro Herrera, with some kibitzing from Tom Lane.
2005-07-07 22:40:02 +02:00
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
<sect1 id="catalog-pg-statistic">
<title><structname>pg_statistic</structname></title>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
2005-06-28 07:09:14 +02:00
<indexterm zone="catalog-pg-statistic">
<primary>pg_statistic</primary>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Various fixes for the SGML docs. Consistently use spaces before/after parentheses in syntax descriptions. Consistently use the present tense when describing the basic purpose of each "DROP" command. Add a few more hyperlinks.
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>
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
and subsequently used by the query planner. Note that all the
Various fixes for the SGML docs. Consistently use spaces before/after parentheses in syntax descriptions. Consistently use the present tense when describing the basic purpose of each "DROP" command. Add a few more hyperlinks.
2007-05-15 21:13:55 +02:00
statistical data is inherently approximate, even assuming that it
is up-to-date.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
doc: avoid saying "inheritance" ... ... when it applies to partitioned relations. This is almost the opposite of 0c06534bd63b, which removed references to "partition" in favour of "child". Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/20220525013248.GO19626@telsasoft.com
2022-07-28 18:21:56 +02:00
If the table has inheritance children or partitions, a second entry with
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structfield>stainherit</structfield> = <literal>true</literal> is also created. This row
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
the results of
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>SELECT <replaceable>column</replaceable> FROM ONLY <replaceable>table</replaceable></literal>.
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<para>
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
for the underlying table column. Currently, entries for index expressions
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
always have <structfield>stainherit</structfield> = <literal>false</literal>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
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
Replace pg_shadow and pg_group by new role-capable catalogs pg_authid and pg_auth_members. There are still many loose ends to finish in this patch (no documentation, no regression tests, no pg_dump support for instance). But I'm going to commit it now anyway so that Alvaro can make some progress on shared dependencies. The catalog changes should be pretty much done.
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>.
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</para>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
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
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
of a salary column might be quite interesting.)
Document all the system views created by initdb (several of these were never documented anywhere, sigh). Centralize the detailed documentation of system views into catalogs.sgml, and provide cross-references.
2003-10-18 00:38:20 +02:00
<link linkend="view-pg-stats"><structname>pg_stats</structname></link>
is a publicly readable view on
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_statistic</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: avoid saying "inheritance" ... ... when it applies to partitioned relations. This is almost the opposite of 0c06534bd63b, which removed references to "partition" in favour of "child". Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/20220525013248.GO19626@telsasoft.com
2022-07-28 18:21:56 +02:00
If true, the stats include values from child tables, not just the
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
values in the specified relation
</para></entry>
Add the ability to store inheritance-tree statistics in pg_statistic, and teach ANALYZE to compute such stats for tables that have subclasses. Per my proposal of yesterday. autovacuum still needs to be taught about running ANALYZE on parent tables when their subclasses change, but the feature is useful even without that.
2009-12-29 21:11:45 +01:00
</row>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
A code number indicating the kind of statistics stored in the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote> of the
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structname>pg_statistic</structname> row.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
An operator used to derive the statistics stored in the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote>. For example, a
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
histogram slot would show the <literal>&lt;</literal> operator
Spell and markup checking
2010-08-17 06:37:21 +02:00
that defines the sort order of the data.
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Zero if the statistics kind does not require an operator.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Numerical statistics of the appropriate kind for the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote>, or null if the slot
Change the parameter_types column of the pg_prepared_statements to be an array of regtype, rather than an array of OIDs. This is likely to be more useful to user, and the type OID can easily be obtained by casting a regtype value to OID. Per suggestion from Tom. Update the documentation and regression tests, and bump the catversion.
2006-01-16 19:15:31 +01:00
kind does not involve numerical values
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Column data values of the appropriate kind for the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<replaceable>N</replaceable>th <quote>slot</quote>, or null if the slot
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
kind does not store any data values. Each array's element
Collect and use element-frequency statistics for arrays. This patch improves selectivity estimation for the array <@, &&, and @> (containment and overlaps) operators. It enables collection of statistics about individual array element values by ANALYZE, and introduces operator-specific estimators that use these stats. In addition, ScalarArrayOpExpr constructs of the forms "const = ANY/ALL (array_column)" and "const <> ANY/ALL (array_column)" are estimated by treating them as variants of the containment operators. Since we still collect scalar-style stats about the array values as a whole, the pg_stats view is expanded to show both these stats and the array-style stats in separate columns. This creates an incompatible change in how stats for tsvector columns are displayed in pg_stats: the stats about lexemes are now displayed in the array-related columns instead of the original scalar-related columns. There are a few loose ends here, notably that it'd be nice to be able to suppress either the scalar-style stats or the array-element stats for columns for which they're not useful. But the patch is in good enough shape to commit for wider testing. Alexander Korotkov, reviewed by Noah Misch and Nathan Boley
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
these columns' type more specifically than <type>anyarray</type>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
</row>
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>.
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_statistic_ext</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
</thead>
<tbody>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
</row>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
The OID of the namespace that contains this statistics object
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
Make stxstattarget nullable To match attstattarget change (commit 4f622503d6d). The logic inside CreateStatistics() is clarified a bit compared to that previous patch, and so here we also update ATExecSetStatistics() to match. Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/4da8d211-d54d-44b9-9847-f2a9f1184c76@eisentraut.org
2024-03-17 12:22:05 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxkeys</structfield> <type>int2vector</type>
(references <link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attnum</structfield>)
</para>
<para>
An array of attribute numbers, indicating which table columns are
covered by this statistics object;
for example a value of <literal>1 3</literal> would
mean that the first and the third table columns are covered
</para></entry>
</row>
Document pg_statistic_ext.stxstattarget Commit d06215d03b added a new attribute to pg_statistic_ext catalog, but failed to add it to document it properly. Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
2020-03-18 16:48:12 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Change type of pg_statistic_ext.stxstattarget Change from int32 to int16, to match attstattarget (changed in 90189eefc1). Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/d6069765-5971-04d3-c10d-e4f7b2e9c459%40eisentraut.org
2023-07-03 07:09:22 +02:00
<structfield>stxstattarget</structfield> <type>int2</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Document pg_statistic_ext.stxstattarget Commit d06215d03b added a new attribute to pg_statistic_ext catalog, but failed to add it to document it properly. Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
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>.
Document pg_statistic_ext.stxstattarget Commit d06215d03b added a new attribute to pg_statistic_ext catalog, but failed to add it to document it properly. Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
2020-03-18 16:48:12 +01:00
A zero value indicates that no statistics should be collected.
Make stxstattarget nullable To match attstattarget change (commit 4f622503d6d). The logic inside CreateStatistics() is clarified a bit compared to that previous patch, and so here we also update ATExecSetStatistics() to match. Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/4da8d211-d54d-44b9-9847-f2a9f1184c76@eisentraut.org
2024-03-17 12:22:05 +01:00
A null value says to use the maximum of the statistics targets of
Copy editing: fix a bunch of misspellings and poor wording. 99% of this is docs, but also a couple of comments. No code changes. Justin Pryzby Discussion: https://postgr.es/m/20200919175804.GE30557@telsasoft.com
2020-09-21 18:43:42 +02:00
the referenced columns, if set, or the system default statistics target.
Fix collection of typos and grammar mistakes in the tree This fixes some comments and documentation new as of Postgres 13. Author: Justin Pryzby Discussion: https://postgr.es/m/20200408165653.GF2228@telsasoft.com
2020-04-10 04:18:39 +02:00
Positive values of <structfield>stxstattarget</structfield>
Document pg_statistic_ext.stxstattarget Commit d06215d03b added a new attribute to pg_statistic_ext catalog, but failed to add it to document it properly. Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
2020-03-18 16:48:12 +01:00
determine the target number of <quote>most common values</quote>
to collect.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Document pg_statistic_ext.stxstattarget Commit d06215d03b added a new attribute to pg_statistic_ext catalog, but failed to add it to document it properly. Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
2020-03-18 16:48:12 +01:00
</row>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Use correct spelling of statistics kind A couple error messages and comments used 'statistic kind', not the correct 'statistics kind'. Fix and backpatch all the way back to 10, where extended statistics were introduced. Backpatch-through: 10
2021-03-23 04:45:26 +01:00
An array containing codes for the enabled statistics kinds;
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
valid values are:
<literal>d</literal> for n-distinct statistics,
docs: fix inconsistencies in markup and case Ensure to properly mark up function parameters in text with <parameter>, avoid using <acronym> for terms which aren't acronyms and properly place the ", and" in a value list. The acronym removal is a follow-up to commit fb72a7b8c3 which removed it for minmax-multi. In passing, also fix an incorrectly cased word. Author: Ekaterina Kiryanova <e.kiryanova@postgrespro.ru> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Discussion: https://postgr.es/m/c050ecbc-80b2-b360-3c1d-9fe6a6a11bb5@postgrespro.ru Backpatch-through: v14
2021-07-15 23:22:58 +02:00
<literal>f</literal> for functional dependency statistics,
<literal>m</literal> for most common values (MCV) list statistics, and
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
<literal>e</literal> for expression statistics
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxexprs</structfield> <type>pg_node_tree</type>
</para>
<para>
Expression trees (in <function>nodeToString()</function>
representation) for statistics object attributes that are not simple
column references. This is a list with one element per expression.
Null if all statistics object attributes are simple references.
</para></entry>
</row>
Rework the pg_statistic_ext catalog Since extended statistic got introduced in PostgreSQL 10, there was a single catalog pg_statistic_ext storing both the definitions and built statistic. That's however problematic when a user is supposed to have access only to the definitions, but not to user data. Consider for example pg_dump on a database with RLS enabled - if the pg_statistic_ext catalog respects RLS (which it should, if it contains user data), pg_dump would not see any records and the result would not define any extended statistics. That would be a surprising behavior. Until now this was not a pressing issue, because the existing types of extended statistic (functional dependencies and ndistinct coefficients) do not include any user data directly. This changed with introduction of MCV lists, which do include most common combinations of values. The easiest way to fix this is to split the pg_statistic_ext catalog into two - one for definitions, one for the built statistic values. The new catalog is called pg_statistic_ext_data, and we're maintaining a 1:1 relationship with the old catalog - either there are matching records in both catalogs, or neither of them. Bumped CATVERSION due to changing system catalog definitions. Author: Dean Rasheed, with improvements by me Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</tbody>
</tgroup>
</table>
<para>
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
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
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
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
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
holds data for extended planner statistics defined in
<link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.
Rework the pg_statistic_ext catalog Since extended statistic got introduced in PostgreSQL 10, there was a single catalog pg_statistic_ext storing both the definitions and built statistic. That's however problematic when a user is supposed to have access only to the definitions, but not to user data. Consider for example pg_dump on a database with RLS enabled - if the pg_statistic_ext catalog respects RLS (which it should, if it contains user data), pg_dump would not see any records and the result would not define any extended statistics. That would be a surprising behavior. Until now this was not a pressing issue, because the existing types of extended statistic (functional dependencies and ndistinct coefficients) do not include any user data directly. This changed with introduction of MCV lists, which do include most common combinations of values. The easiest way to fix this is to split the pg_statistic_ext catalog into two - one for definitions, one for the built statistic values. The new catalog is called pg_statistic_ext_data, and we're maintaining a 1:1 relationship with the old catalog - either there are matching records in both catalogs, or neither of them. Bumped CATVERSION due to changing system catalog definitions. Author: Dean Rasheed, with improvements by me Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
Each row in this catalog corresponds to a <firstterm>statistics object</firstterm>
Improve <xref> vs. <command> formatting in the documentation SQL commands are generally marked up as <command>, except when a link to a reference page is used using <xref>. But the latter doesn't create monospace markup, so this looks strange especially when a paragraph contains a mix of links and non-links. We considered putting <command> in the <refentrytitle> on the target side, but that creates some formatting side effects elsewhere. Generally, it seems safer to solve this on the link source side. We can't put the <xref> inside the <command>; the DTD doesn't allow this. DocBook 5 would allow the <command> to have the linkend attribute itself, but we are not there yet. So to solve this for now, convert the <xref>s to <link> plus <command>. This gives the correct look and also gives some more flexibility what we can put into the link text (e.g., subcommands or other clauses). In the future, these could then be converted to DocBook 5 style. I haven't converted absolutely all xrefs to SQL command reference pages, only those where we care about the appearance of the link text or where it was otherwise appropriate to make the appearance match a bit better. Also in some cases, the links where repetitive, so in those cases the links where just removed and replaced by a plain <command>. In cases where we just want the link and don't specifically care about the generated link text (typically phrased "for further information see <xref ...>") the xref is kept. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
created with <link linkend="sql-createstatistics"><command>CREATE STATISTICS</command></link>.
Rework the pg_statistic_ext catalog Since extended statistic got introduced in PostgreSQL 10, there was a single catalog pg_statistic_ext storing both the definitions and built statistic. That's however problematic when a user is supposed to have access only to the definitions, but not to user data. Consider for example pg_dump on a database with RLS enabled - if the pg_statistic_ext catalog respects RLS (which it should, if it contains user data), pg_dump would not see any records and the result would not define any extended statistics. That would be a surprising behavior. Until now this was not a pressing issue, because the existing types of extended statistic (functional dependencies and ndistinct coefficients) do not include any user data directly. This changed with introduction of MCV lists, which do include most common combinations of values. The easiest way to fix this is to split the pg_statistic_ext catalog into two - one for definitions, one for the built statistic values. The new catalog is called pg_statistic_ext_data, and we're maintaining a 1:1 relationship with the old catalog - either there are matching records in both catalogs, or neither of them. Bumped CATVERSION due to changing system catalog definitions. Author: Dean Rasheed, with improvements by me Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</para>
Add stxdinherit flag to pg_statistic_ext_data Add pg_statistic_ext_data.stxdinherit flag, so that for each extended statistics definition we can store two versions of data - one for the relation alone, one for the whole inheritance tree. This is analogous to pg_statistic.stainherit, but we failed to include such flag in catalogs for extended statistics, and we had to work around it (see commits 859b3003de, 36c4bc6e72 and 20b9fa308e). This changes the relationship between the two catalogs storing extended statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until now, there was a simple 1:1 mapping - for each definition there was one pg_statistic_ext_data row, and this row was inserted while creating the statistics (and then updated during ANALYZE). With the stxdinherit flag, we don't know how many rows there will be (child relations may be added after the statistics object is defined), so there may be up to two rows. We could make CREATE STATISTICS to always create both rows, but that seems wasteful - without partitioning we only need stxdinherit=false rows, and declaratively partitioned tables need only stxdinherit=true. So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS, and instead make that a responsibility of ANALYZE. Which is what we do for regular statistics too. Patch by me, with extensive improvements and fixes by Justin Pryzby. Author: Tomas Vondra, Justin Pryzby Reviewed-by: Tomas Vondra, Justin Pryzby Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
<para>
Normally there is one entry, with <structfield>stxdinherit</structfield> =
<literal>false</literal>, for each statistics object that has been analyzed.
doc: avoid saying "inheritance" ... ... when it applies to partitioned relations. This is almost the opposite of 0c06534bd63b, which removed references to "partition" in favour of "child". Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/20220525013248.GO19626@telsasoft.com
2022-07-28 18:21:56 +02:00
If the table has inheritance children or partitions, a second entry with
Add stxdinherit flag to pg_statistic_ext_data Add pg_statistic_ext_data.stxdinherit flag, so that for each extended statistics definition we can store two versions of data - one for the relation alone, one for the whole inheritance tree. This is analogous to pg_statistic.stainherit, but we failed to include such flag in catalogs for extended statistics, and we had to work around it (see commits 859b3003de, 36c4bc6e72 and 20b9fa308e). This changes the relationship between the two catalogs storing extended statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until now, there was a simple 1:1 mapping - for each definition there was one pg_statistic_ext_data row, and this row was inserted while creating the statistics (and then updated during ANALYZE). With the stxdinherit flag, we don't know how many rows there will be (child relations may be added after the statistics object is defined), so there may be up to two rows. We could make CREATE STATISTICS to always create both rows, but that seems wasteful - without partitioning we only need stxdinherit=false rows, and declaratively partitioned tables need only stxdinherit=true. So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS, and instead make that a responsibility of ANALYZE. Which is what we do for regular statistics too. Patch by me, with extensive improvements and fixes by Justin Pryzby. Author: Tomas Vondra, Justin Pryzby Reviewed-by: Tomas Vondra, Justin Pryzby Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
<structfield>stxdinherit</structfield> = <literal>true</literal> is also created.
This row represents the statistics object over the inheritance tree, i.e.,
statistics for the data you'd see with
<literal>SELECT * FROM <replaceable>table</replaceable>*</literal>,
whereas the <structfield>stxdinherit</structfield> = <literal>false</literal> row
represents the results of
<literal>SELECT * FROM ONLY <replaceable>table</replaceable></literal>.
</para>
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
2019-10-06 20:14:45 +02:00
<para>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
Like <link linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link>,
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
with <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>) that only exposes
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxoid</structfield> <type>oid</type>
(references <link linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
Extended statistics object containing the definition for this data
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rework the pg_statistic_ext catalog Since extended statistic got introduced in PostgreSQL 10, there was a single catalog pg_statistic_ext storing both the definitions and built statistic. That's however problematic when a user is supposed to have access only to the definitions, but not to user data. Consider for example pg_dump on a database with RLS enabled - if the pg_statistic_ext catalog respects RLS (which it should, if it contains user data), pg_dump would not see any records and the result would not define any extended statistics. That would be a surprising behavior. Until now this was not a pressing issue, because the existing types of extended statistic (functional dependencies and ndistinct coefficients) do not include any user data directly. This changed with introduction of MCV lists, which do include most common combinations of values. The easiest way to fix this is to split the pg_statistic_ext catalog into two - one for definitions, one for the built statistic values. The new catalog is called pg_statistic_ext_data, and we're maintaining a 1:1 relationship with the old catalog - either there are matching records in both catalogs, or neither of them. Bumped CATVERSION due to changing system catalog definitions. Author: Dean Rasheed, with improvements by me Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
2019-06-13 17:19:21 +02:00
</row>
Add stxdinherit flag to pg_statistic_ext_data Add pg_statistic_ext_data.stxdinherit flag, so that for each extended statistics definition we can store two versions of data - one for the relation alone, one for the whole inheritance tree. This is analogous to pg_statistic.stainherit, but we failed to include such flag in catalogs for extended statistics, and we had to work around it (see commits 859b3003de, 36c4bc6e72 and 20b9fa308e). This changes the relationship between the two catalogs storing extended statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until now, there was a simple 1:1 mapping - for each definition there was one pg_statistic_ext_data row, and this row was inserted while creating the statistics (and then updated during ANALYZE). With the stxdinherit flag, we don't know how many rows there will be (child relations may be added after the statistics object is defined), so there may be up to two rows. We could make CREATE STATISTICS to always create both rows, but that seems wasteful - without partitioning we only need stxdinherit=false rows, and declaratively partitioned tables need only stxdinherit=true. So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS, and instead make that a responsibility of ANALYZE. Which is what we do for regular statistics too. Patch by me, with extensive improvements and fixes by Justin Pryzby. Author: Tomas Vondra, Justin Pryzby Reviewed-by: Tomas Vondra, Justin Pryzby Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stxdinherit</structfield> <type>bool</type>
</para>
<para>
doc: avoid saying "inheritance" ... ... when it applies to partitioned relations. This is almost the opposite of 0c06534bd63b, which removed references to "partition" in favour of "child". Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://postgr.es/m/20220525013248.GO19626@telsasoft.com
2022-07-28 18:21:56 +02:00
If true, the stats include values from child tables, not just the
Add stxdinherit flag to pg_statistic_ext_data Add pg_statistic_ext_data.stxdinherit flag, so that for each extended statistics definition we can store two versions of data - one for the relation alone, one for the whole inheritance tree. This is analogous to pg_statistic.stainherit, but we failed to include such flag in catalogs for extended statistics, and we had to work around it (see commits 859b3003de, 36c4bc6e72 and 20b9fa308e). This changes the relationship between the two catalogs storing extended statistics objects (pg_statistic_ext and pg_statistic_ext_data). Until now, there was a simple 1:1 mapping - for each definition there was one pg_statistic_ext_data row, and this row was inserted while creating the statistics (and then updated during ANALYZE). With the stxdinherit flag, we don't know how many rows there will be (child relations may be added after the statistics object is defined), so there may be up to two rows. We could make CREATE STATISTICS to always create both rows, but that seems wasteful - without partitioning we only need stxdinherit=false rows, and declaratively partitioned tables need only stxdinherit=true. So we no longer initialize pg_statistic_ext_data in CREATE STATISTICS, and instead make that a responsibility of ANALYZE. Which is what we do for regular statistics too. Patch by me, with extensive improvements and fixes by Justin Pryzby. Author: Tomas Vondra, Justin Pryzby Reviewed-by: Tomas Vondra, Justin Pryzby Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
2022-01-16 13:37:56 +01:00
values in the specified relation
</para></entry>
</row>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
N-distinct counts, serialized as <structname>pg_ndistinct</structname> type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
Functional dependency statistics, serialized
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
as <structname>pg_dependencies</structname> type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: improve docs about pg_statistic_ext_data. Commit aa087ec64 was a bit over-hasty about the doc changes needed while splitting pg_statistic_ext_data off from pg_statistic_ext. It duplicated one para and inserted another in what seems to me to be the wrong section. Fix that up, and in passing do some minor copy-editing. Per report from noborusai. Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com
2019-10-06 20:14:45 +02:00
<structname>pg_mcv_list</structname> type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add support for multivariate MCV lists Introduce a third extended statistic type, supported by the CREATE STATISTICS command - MCV lists, a generalization of the statistic already built and used for individual columns. Compared to the already supported types (n-distinct coefficients and functional dependencies), MCV lists are more complex, include column values and allow estimation of much wider range of common clauses (equality and inequality conditions, IS NULL, IS NOT NULL etc.). Similarly to the other types, a new pseudo-type (pg_mcv_list) is used. Author: Tomas Vondra Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com
2019-03-27 18:32:18 +01:00
</row>
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: move some catalogs.sgml entries to the right place. pg_statistic_ext_data.stxdexpr was listed under the wrong catalog, as was pg_stats_ext.exprs. Also there was a bogus entry for pg_statistic_ext_data.stxexprs. Apparently a merge failure in commit a4d75c86b. Guillaume Lelarge and Tom Lane Discussion: https://postgr.es/m/CAECtzeUHw+w64eUFVeV_2FJviAw6oZ0wNLkmU843ZH4hAQfiWg@mail.gmail.com
2021-05-25 00:03:47 +02:00
<structfield>stxdexpr</structfield> <type>pg_statistic[]</type>
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
</para>
<para>
Doc: move some catalogs.sgml entries to the right place. pg_statistic_ext_data.stxdexpr was listed under the wrong catalog, as was pg_stats_ext.exprs. Also there was a bogus entry for pg_statistic_ext_data.stxexprs. Apparently a merge failure in commit a4d75c86b. Guillaume Lelarge and Tom Lane Discussion: https://postgr.es/m/CAECtzeUHw+w64eUFVeV_2FJviAw6oZ0wNLkmU843ZH4hAQfiWg@mail.gmail.com
2021-05-25 00:03:47 +02:00
Per-expression statistics, serialized as an array of
<structname>pg_statistic</structname> type
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
</para></entry>
</row>
Edit SGML documentation related to extended statistics. Use the "statistics object" terminology uniformly here too. Assorted copy-editing. Put new catalogs.sgml sections into alphabetical order.
2017-05-15 01:15:52 +02:00
</tbody>
</tgroup>
</table>
</sect1>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
replication see <xref linkend="logical-replication"/>.
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</para>
<para>
Unlike most system catalogs, <structname>pg_subscription</structname> is
Assorted minor doc/comment fixes. Identify pg_replication_origin as a shared catalog in catalogs.sgml, using the same boilerplate wording used for most other shared catalogs (and tweak another place where someone had randomly deviated from that boilerplate). Make an example in mmgr/README more consistent with surrounding text. Update an obsolete cross-reference in a comment in storage/block.h. Zhuo Ql Discussion: https://postgr.es/m/44296255.1819230.1524889719001@mail.yahoo.com
2018-04-28 17:46:15 +02:00
shared across all databases of a cluster: there is only one copy
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
of <structname>pg_subscription</structname> per cluster, not one per
database.
</para>
<para>
psql: Add tab completion for logical replication Add tab completion for publications and subscriptions. Also, to be able to get a list of subscriptions, make pg_subscription world-readable but revoke access to subconninfo using column privileges. From: Michael Paquier <michael.paquier@gmail.com>
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.
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</para>
<table>
<title><structname>pg_subscription</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow logical replication to transfer data in binary format. This patch adds a "binary" option to CREATE/ALTER SUBSCRIPTION. When that's set, the publisher will send data using the data type's typsend function if any, rather than typoutput. This is generally faster, if slightly less robust. As committed, we won't try to transfer user-defined array or composite types in binary, for fear that type OIDs won't match at the subscriber. This might be changed later, but it seems like fit material for a follow-on patch. Dave Cramer, reviewed by Daniel Gustafsson, Petr Jelinek, and others; adjusted some by me Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com
2020-07-18 18:44:51 +02:00
OID of the database that the subscription resides in
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
Reorder subskiplsn in pg_subscription to avoid alignment issues. The column 'subskiplsn' uses TYPALIGN_DOUBLE (which has 4 bytes alignment on AIX) for storage. But the C Struct (Form_pg_subscription) has 8-byte alignment for this field, so retrieving it from storage causes an unaligned read. To fix this, we rearranged the 'subskiplsn' column in the catalog so that it naturally comes at an 8-byte boundary. We have fixed a similar problem in commit f3b421da5f. This patch adds a test to avoid a similar mistake in the future. Reported-by: Noah Misch Diagnosed-by: Noah Misch, Masahiko Sawada, Amit Kapila Author: Masahiko Sawada Reviewed-by: Noah Misch, Amit Kapila Discussion: https://postgr.es/m/20220401074423.GC3682158@rfd.leadboat.com https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-04-07 06:09:25 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subskiplsn</structfield> <type>pg_lsn</type>
</para>
<para>
Finish LSN of the transaction whose changes are to be skipped, if a valid
LSN; otherwise <literal>0/0</literal>.
</para></entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow logical replication to transfer data in binary format. This patch adds a "binary" option to CREATE/ALTER SUBSCRIPTION. When that's set, the publisher will send data using the data type's typsend function if any, rather than typoutput. This is generally faster, if slightly less robust. As committed, we won't try to transfer user-defined array or composite types in binary, for fear that type OIDs won't match at the subscriber. This might be changed later, but it seems like fit material for a follow-on patch. Dave Cramer, reviewed by Daniel Gustafsson, Petr Jelinek, and others; adjusted some by me Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
Doc: Add a description of substream in pg_subscription. Commit 464824323e added a new column substream in pg_subscription but forgot to update the docs. Reported-by: Peter Smith Author: Amit Kapila Reviewed-by: Peter Smith Discussion: https://postgr.es/m/CAHut+PuPGGASnh2Dy37VYODKULVQo-5oE=Shc6gwtRizDt==cA@mail.gmail.com
2021-03-17 03:10:23 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Perform apply of large transactions by parallel workers. Currently, for large transactions, the publisher sends the data in multiple streams (changes divided into chunks depending upon logical_decoding_work_mem), and then on the subscriber-side, the apply worker writes the changes into temporary files and once it receives the commit, it reads from those files and applies the entire transaction. To improve the performance of such transactions, we can instead allow them to be applied via parallel workers. In this approach, we assign a new parallel apply worker (if available) as soon as the xact's first stream is received and the leader apply worker will send changes to this new worker via shared memory. The parallel apply worker will directly apply the change instead of writing it to temporary files. However, if the leader apply worker times out while attempting to send a message to the parallel apply worker, it will switch to "partial serialize" mode - in this mode, the leader serializes all remaining changes to a file and notifies the parallel apply workers to read and apply them at the end of the transaction. We use a non-blocking way to send the messages from the leader apply worker to the parallel apply to avoid deadlocks. We keep this parallel apply assigned till the transaction commit is received and also wait for the worker to finish at commit. This preserves commit ordering and avoid writing to and reading from files in most cases. We still need to spill if there is no worker available. This patch also extends the SUBSCRIPTION 'streaming' parameter so that the user can control whether to apply the streaming transaction in a parallel apply worker or spill the change to disk. The user can set the streaming parameter to 'on/off', or 'parallel'. The parameter value 'parallel' means the streaming will be applied via a parallel apply worker, if available. The parameter value 'on' means the streaming transaction will be spilled to disk. The default value is 'off' (same as current behaviour). In addition, the patch extends the logical replication STREAM_ABORT message so that abort_lsn and abort_time can also be sent which can be used to update the replication origin in parallel apply worker when the streaming transaction is aborted. Because this message extension is needed to support parallel streaming, parallel streaming is not supported for publications on servers < PG16. Author: Hou Zhijie, Wang wei, Amit Kapila with design inputs from Sawada Masahiko Reviewed-by: Sawada Masahiko, Peter Smith, Dilip Kumar, Shi yu, Kuroda Hayato, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-09 02:30:39 +01:00
<structfield>substream</structfield> <type>char</type>
Doc: Add a description of substream in pg_subscription. Commit 464824323e added a new column substream in pg_subscription but forgot to update the docs. Reported-by: Peter Smith Author: Amit Kapila Reviewed-by: Peter Smith Discussion: https://postgr.es/m/CAHut+PuPGGASnh2Dy37VYODKULVQo-5oE=Shc6gwtRizDt==cA@mail.gmail.com
2021-03-17 03:10:23 +01:00
</para>
<para>
Perform apply of large transactions by parallel workers. Currently, for large transactions, the publisher sends the data in multiple streams (changes divided into chunks depending upon logical_decoding_work_mem), and then on the subscriber-side, the apply worker writes the changes into temporary files and once it receives the commit, it reads from those files and applies the entire transaction. To improve the performance of such transactions, we can instead allow them to be applied via parallel workers. In this approach, we assign a new parallel apply worker (if available) as soon as the xact's first stream is received and the leader apply worker will send changes to this new worker via shared memory. The parallel apply worker will directly apply the change instead of writing it to temporary files. However, if the leader apply worker times out while attempting to send a message to the parallel apply worker, it will switch to "partial serialize" mode - in this mode, the leader serializes all remaining changes to a file and notifies the parallel apply workers to read and apply them at the end of the transaction. We use a non-blocking way to send the messages from the leader apply worker to the parallel apply to avoid deadlocks. We keep this parallel apply assigned till the transaction commit is received and also wait for the worker to finish at commit. This preserves commit ordering and avoid writing to and reading from files in most cases. We still need to spill if there is no worker available. This patch also extends the SUBSCRIPTION 'streaming' parameter so that the user can control whether to apply the streaming transaction in a parallel apply worker or spill the change to disk. The user can set the streaming parameter to 'on/off', or 'parallel'. The parameter value 'parallel' means the streaming will be applied via a parallel apply worker, if available. The parameter value 'on' means the streaming transaction will be spilled to disk. The default value is 'off' (same as current behaviour). In addition, the patch extends the logical replication STREAM_ABORT message so that abort_lsn and abort_time can also be sent which can be used to update the replication origin in parallel apply worker when the streaming transaction is aborted. Because this message extension is needed to support parallel streaming, parallel streaming is not supported for publications on servers < PG16. Author: Hou Zhijie, Wang wei, Amit Kapila with design inputs from Sawada Masahiko Reviewed-by: Sawada Masahiko, Peter Smith, Dilip Kumar, Shi yu, Kuroda Hayato, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-09 02:30:39 +01:00
Controls how to handle the streaming of in-progress transactions:
<literal>f</literal> = disallow streaming of in-progress transactions,
<literal>t</literal> = spill the changes of in-progress transactions to
disk and apply at once after the transaction is committed on the
publisher and received by the subscriber,
<literal>p</literal> = apply changes directly using a parallel apply
doc: Fix some grammar and inconsistent tags Author: Ekaterina Kiryanova, Elena Indrupskaya, Oleg Sibiryakov, Maxim Yablokov Discussion: https://postgr.es/m/4c2a430b-32e2-44e2-aeca-03b7db6824e4@postgrespro.ru
2023-10-23 02:58:55 +02:00
worker if available (same as <literal>t</literal> if no worker is
available)
Doc: Add a description of substream in pg_subscription. Commit 464824323e added a new column substream in pg_subscription but forgot to update the docs. Reported-by: Peter Smith Author: Amit Kapila Reviewed-by: Peter Smith Discussion: https://postgr.es/m/CAHut+PuPGGASnh2Dy37VYODKULVQo-5oE=Shc6gwtRizDt==cA@mail.gmail.com
2021-03-17 03:10:23 +01:00
</para></entry>
</row>
Add support for prepared transactions to built-in logical replication. To add support for streaming transactions at prepare time into the built-in logical replication, we need to do the following things: * Modify the output plugin (pgoutput) to implement the new two-phase API callbacks, by leveraging the extended replication protocol. * Modify the replication apply worker, to properly handle two-phase transactions by replaying them on prepare. * Add a new SUBSCRIPTION option "two_phase" to allow users to enable two-phase transactions. We enable the two_phase once the initial data sync is over. We however must explicitly disable replication of two-phase transactions during replication slot creation, even if the plugin supports it. We don't need to replicate the changes accumulated during this phase, and moreover, we don't have a replication connection open so we don't know where to send the data anyway. The streaming option is not allowed with this new two_phase option. This can be done as a separate patch. We don't allow to toggle two_phase option of a subscription because it can lead to an inconsistent replica. For the same reason, we don't allow to refresh the publication once the two_phase is enabled for a subscription unless copy_data option is false. Author: Peter Smith, Ajin Cherian and Amit Kapila based on previous work by Nikhil Sontakke and Stas Kelvich Reviewed-by: Amit Kapila, Sawada Masahiko, Vignesh C, Dilip Kumar, Takamichi Osumi, Greg Nancarrow Tested-By: Haiying Tang Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru Discussion: https://postgr.es/m/CAA4eK1+opiV4aFTmWWUF9h_32=HfPOW9vZASHarT0UA5oBrtGw@mail.gmail.com
2021-07-14 04:03:50 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subtwophasestate</structfield> <type>char</type>
</para>
<para>
State codes for two-phase mode:
<literal>d</literal> = disabled,
<literal>p</literal> = pending enablement,
<literal>e</literal> = enabled
</para></entry>
</row>
Optionally disable subscriptions on error. Logical replication apply workers for a subscription can easily get stuck in an infinite loop of attempting to apply a change, triggering an error (such as a constraint violation), exiting with the error written to the subscription server log, and restarting. To partially remedy the situation, this patch adds a new subscription option named 'disable_on_error'. To be consistent with old behavior, this option defaults to false. When true, both the tablesync worker and apply worker catch any errors thrown and disable the subscription in order to break the loop. The error is still also written in the logs. Once the subscription is disabled, users can either manually resolve the conflict/error or skip the conflicting transaction by using pg_replication_origin_advance() function. After resolving the conflict, users need to enable the subscription to allow apply process to proceed. Author: Osumi Takamichi and Mark Dilger Reviewed-by: Greg Nancarrow, Vignesh C, Amit Kapila, Wang wei, Tang Haiying, Peter Smith, Masahiko Sawada, Shi Yu Discussion : https://postgr.es/m/DB35438F-9356-4841-89A0-412709EBD3AB%40enterprisedb.com
2022-03-14 05:02:40 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subdisableonerr</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will be disabled if one of its workers
detects an error
</para></entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Document new pg_subscription columns. Commit 482675987bcdffb390ae735cfd5f34b485ae97c6 and commit c3afe8cf5a1e465bd71e48e4bc717f5bfdc7a7d6 forgot to take care of this. Noriyoshi Shinoda Discussion: http://postgr.es/m/DM4PR84MB17345D8760165F14A199B81CEE9A9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2023-04-11 17:00:36 +02:00
<structfield>subpasswordrequired</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will be required to specify a password
for authentication
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subrunasowner</structfield> <type>bool</type>
</para>
<para>
If true, the subscription will be run with the permissions
of the subscription owner
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Add a failover option to subscriptions. This commit introduces a new subscription option named 'failover', which provides users with the ability to set the failover property of the replication slot on the publisher when creating or altering a subscription. This uses the replication commands introduced by commit 7329240437 to enable the failover option for a logical replication slot. If the failover option is set to true, the associated replication slots (i.e. the main slot and the table sync slots) in the upstream database are enabled to be synchronized to the standbys. Note that the capability to sync the replication slots will be added in subsequent commits. Thanks to Masahiko Sawada for the design inputs. Author: Shveta Malik, Hou Zhijie, Ajin Cherian Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
<structfield>subfailover</structfield> <type>bool</type>
</para>
<para>
If true, the associated replication slots (i.e. the main slot and the
table sync slots) in the upstream database are enabled to be
synchronized to the standbys
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<structfield>subconninfo</structfield> <type>text</type>
</para>
<para>
Connection string to the upstream database
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow logical replication to transfer data in binary format. This patch adds a "binary" option to CREATE/ALTER SUBSCRIPTION. When that's set, the publisher will send data using the data type's typsend function if any, rather than typoutput. This is generally faster, if slightly less robust. As committed, we won't try to transfer user-defined array or composite types in binary, for fear that type OIDs won't match at the subscriber. This might be changed later, but it seems like fit material for a follow-on patch. Dave Cramer, reviewed by Daniel Gustafsson, Petr Jelinek, and others; adjusted some by me Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow logical replication to transfer data in binary format. This patch adds a "binary" option to CREATE/ALTER SUBSCRIPTION. When that's set, the publisher will send data using the data type's typsend function if any, rather than typoutput. This is generally faster, if slightly less robust. As committed, we won't try to transfer user-defined array or composite types in binary, for fear that type OIDs won't match at the subscriber. This might be changed later, but it seems like fit material for a follow-on patch. Dave Cramer, reviewed by Daniel Gustafsson, Petr Jelinek, and others; adjusted some by me Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com
2020-07-18 18:44:51 +02:00
The <varname>synchronous_commit</varname>
setting for the subscription's workers to use
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Allow logical replication to transfer data in binary format. This patch adds a "binary" option to CREATE/ALTER SUBSCRIPTION. When that's set, the publisher will send data using the data type's typsend function if any, rather than typoutput. This is generally faster, if slightly less robust. As committed, we won't try to transfer user-defined array or composite types in binary, for fear that type OIDs won't match at the subscriber. This might be changed later, but it seems like fit material for a follow-on patch. Dave Cramer, reviewed by Daniel Gustafsson, Petr Jelinek, and others; adjusted some by me Discussion: https://postgr.es/m/CADK3HH+R3xMn=8t3Ct+uD+qJ1KD=Hbif5NFMJ+d5DkoCzp6Vgw@mail.gmail.com
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
see <xref linkend="logical-replication-publication"/>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
Allow users to skip logical replication of data having origin. This patch adds a new SUBSCRIPTION parameter "origin". It specifies whether the subscription will request the publisher to only send changes that don't have an origin or send changes regardless of origin. Setting it to "none" means that the subscription will request the publisher to only send changes that have no origin associated. Setting it to "any" means that the publisher sends changes regardless of their origin. The default is "any". Usage: CREATE SUBSCRIPTION sub1 CONNECTION 'dbname=postgres port=9999' PUBLICATION pub1 WITH (origin = none); This can be used to avoid loops (infinite replication of the same data) among replication nodes. This feature allows filtering only the replication data originating from WAL but for initial sync (initial copy of table data) we don't have such a facility as we can only distinguish the data based on origin from WAL. As a follow-up patch, we are planning to forbid the initial sync if the origin is specified as none and we notice that the publication tables were also replicated from other publishers to avoid duplicate data or loops. We forbid to allow creating origin with names 'none' and 'any' to avoid confusion with the same name options. Author: Vignesh C, Amit Kapila Reviewed-By: Peter Smith, Amit Kapila, Dilip Kumar, Shi yu, Ashutosh Bapat, Hayato Kuroda Discussion: https://postgr.es/m/CALDaNm0gwjY_4HFxvvty01BOT01q_fJLKQ3pWP9=9orqubhjcQ@mail.gmail.com
2022-07-21 05:17:38 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>suborigin</structfield> <type>text</type>
</para>
<para>
The origin value must be either <literal>none</literal> or
<literal>any</literal>. The default is <literal>any</literal>.
If <literal>none</literal>, the subscription will request the publisher
to only send changes that don't have an origin. If
<literal>any</literal>, the publisher sends changes regardless of their
origin.
</para></entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</tbody>
</tgroup>
</table>
</sect1>
Rewrite of planner statistics-gathering code. ANALYZE is now available as a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
2001-05-07 02:43:27 +02:00
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
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
doc: Make SQL command names in the catalog documentation links In passing, fix the initdb references to be <application> rather than <command>, which is what we normally use. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION ... REFRESH
PUBLICATION</command></link>.
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
</para>
<table>
<title><structname>pg_subscription_rel</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
State code:
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>i</literal> = initialize,
<literal>d</literal> = data is being copied,
Allow multiple xacts during table sync in logical replication. For the initial table data synchronization in logical replication, we use a single transaction to copy the entire table and then synchronize the position in the stream with the main apply worker. There are multiple downsides of this approach: (a) We have to perform the entire copy operation again if there is any error (network breakdown, error in the database operation, etc.) while we synchronize the WAL position between tablesync worker and apply worker; this will be onerous especially for large copies, (b) Using a single transaction in the synchronization-phase (where we can receive WAL from multiple transactions) will have the risk of exceeding the CID limit, (c) The slot will hold the WAL till the entire sync is complete because we never commit till the end. This patch solves all the above downsides by allowing multiple transactions during the tablesync phase. The initial copy is done in a single transaction and after that, we commit each transaction as we receive. To allow recovery after any error or crash, we use a permanent slot and origin to track the progress. The slot and origin will be removed once we finish the synchronization of the table. We also remove slot and origin of tablesync workers if the user performs DROP SUBSCRIPTION .. or ALTER SUBSCRIPTION .. REFERESH and some of the table syncs are still not finished. The commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION and ALTER SUBSCRIPTION ... SET PUBLICATION ... with refresh option as true cannot be executed inside a transaction block because they can now drop the slots for which we have no provision to rollback. This will also open up the path for logical replication of 2PC transactions on the subscriber side. Previously, we can't do that because of the requirement of maintaining a single transaction in tablesync workers. Bump catalog version due to change of state in the catalog (pg_subscription_rel). Author: Peter Smith, Amit Kapila, and Takamichi Osumi Reviewed-by: Ajin Cherian, Petr Jelinek, Hou Zhijie and Amit Kapila Discussion: https://postgr.es/m/CAA4eK1KHJxaZS-fod-0fey=0tq3=Gkn4ho=8N4-5HWiCfu0H1A@mail.gmail.com
2021-02-12 03:11:51 +01:00
<literal>f</literal> = finished table copy,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>s</literal> = synchronized,
<literal>r</literal> = ready (normal replication)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Correctly mark pg_subscription_rel.srsublsn as nullable. The code has always set this column to NULL when it's not valid, but the catalog header's description failed to reflect that, as did the SGML docs, as did some of the code. To prevent future coding errors of the same ilk, let's hide the field from C code as though it were variable-length (which, in a sense, it is). As with commit 72eab84a5, we can only fix this cleanly in HEAD and v13; the problem extends further back but we'll need some klugery in the released branches. Discussion: https://postgr.es/m/367660.1595202498@sss.pgh.pa.us
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Logical replication support for initial data copy Add functionality for a new subscription to copy the initial data in the tables and then sync with the ongoing apply process. For the copying, add a new internal COPY option to have the COPY source data provided by a callback function. The initial data copy works on the subscriber by receiving COPY data from the publisher and then providing it locally into a COPY that writes to the destination table. A WAL receiver can now execute full SQL commands. This is used here to obtain information about tables and publications. Several new options were added to CREATE and ALTER SUBSCRIPTION to control whether and when initial table syncing happens. Change pg_dump option --no-create-subscription-slots to --no-subscription-connect and use the new CREATE SUBSCRIPTION ... NOCONNECT option for that. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com> Tested-by: Erik Rijkers <er@xs4all.nl>
2017-03-23 13:36:36 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_tablespace</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</row>
Document pg_tablespace.spcoptions. This should have been part of the original tablespace-options patch, but I overlooked the need to update this portion of the documentation.
2010-01-10 02:23:08 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Tablespace-level options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Document pg_tablespace.spcoptions. This should have been part of the original tablespace-options patch, but I overlooked the need to update this portion of the documentation.
2010-01-10 02:23:08 +01:00
</row>
Tablespaces. Alternate database locations are dead, long live tablespaces. There are various things left to do: contrib dbsize and oid2name modules need work, and so does the documentation. Also someone should think about COMMENT ON TABLESPACE and maybe RENAME TABLESPACE. Also initlocation is dead, it just doesn't know it yet. Gavin Sherry and Tom Lane.
2004-06-18 08:14:31 +02:00
</tbody>
</tgroup>
</table>
</sect1>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
languages. See <xref linkend="sql-createtransform"/> for more information.
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_transform</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</row>
</thead>
<tbody>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: fix assorted misstatements of fact in catalog & system view docs. I made up a very crude hack to compare the docs with reality (as embodied in the system catalogs) ... and indeed they don't match everywhere. Missing oid columns, wrong data types, wrong "references" links, columns listed in the wrong order. None of this seems quite important enough to back-patch.
2020-05-10 01:09:44 +02:00
</row>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
if the default behavior should be used.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
stored if the default behavior should be used.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-trigger">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_trigger</structname></title>
<indexterm zone="catalog-pg-trigger">
<primary>pg_trigger</primary>
</indexterm>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<para>
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
The catalog <structname>pg_trigger</structname> stores triggers on tables
and views.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
See <xref linkend="sql-createtrigger"/>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
for more information.
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_trigger</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
Record parents of triggers This let us get rid of a recently introduced ugly hack (commit 1fa846f1c9af). Author: Álvaro Herrera Reviewed-by: Amit Langote, Tom Lane Discussion: https://postgr.es/m/20200217215641.GA29784@alvherre.pgsql
2020-02-27 17:23:33 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Parent trigger that this trigger is cloned from (this happens when
partitions are created or attached to a partitioned table);
zero if not a clone
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Record parents of triggers This let us get rid of a recently introduced ugly hack (commit 1fa846f1c9af). Author: Álvaro Herrera Reviewed-by: Amit Langote, Tom Lane Discussion: https://postgr.es/m/20200217215641.GA29784@alvherre.pgsql
2020-02-27 17:23:33 +01:00
</row>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
Controls in which <xref linkend="guc-session-replication-role"/> modes
Remove tabs in SGML files.
2007-03-22 16:46:56 +01:00
the trigger fires.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
(zero if trigger is not for a referential integrity constraint)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
</row>
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
(zero if trigger is not for one of these types of constraint)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add system catalog columns pg_constraint.conindid and pg_trigger.tgconstrindid. conindid is the index supporting a constraint. We can use this not only for unique/primary-key constraints, but also foreign-key constraints, which depend on the unique index that constrains the referenced columns. tgconstrindid is just copied from the constraint's conindid field, or is zero for triggers not associated with constraints. This is mainly intended as infrastructure for upcoming patches, but it has some virtue in itself, since it exposes a relationship that you formerly had to grovel in pg_depend to determine. I simplified one information_schema view accordingly. (There is a pg_dump query that could also use conindid, but I left it alone because it wasn't clear it'd get any faster.)
2009-07-28 04:56:31 +02:00
</row>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
The <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> entry associated with the trigger
(zero if trigger is not for a constraint)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</row>
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
representation) for the trigger's <literal>WHEN</literal> condition, or null
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
if none
</para></entry>
Add a WHEN clause to CREATE TRIGGER, allowing a boolean expression to be checked to determine whether the trigger should be fired. For BEFORE triggers this is mostly a matter of spec compliance; but for AFTER triggers it can provide a noticeable performance improvement, since queuing of a deferred trigger event and re-fetching of the row(s) at end of statement can be short-circuited if the trigger does not need to be fired. Takahiro Itagaki, reviewed by KaiGai Kohei.
2009-11-20 21:38:12 +01:00
</row>
Implement syntax for transition tables in AFTER triggers. This is infrastructure for the complete SQL standard feature. No support is included at this point for execution nodes or PLs. The intent is to add that soon. As this patch leaves things, standard syntax can create tuplestores to contain old and/or new versions of rows affected by a statement. References to these tuplestores are in the TriggerData structure. C triggers can access the tuplestores directly, so they are usable, but they cannot yet be referenced within a SQL statement.
2016-11-04 16:49:50 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Implement syntax for transition tables in AFTER triggers. This is infrastructure for the complete SQL standard feature. No support is included at this point for execution nodes or PLs. The intent is to add that soon. As this patch leaves things, standard syntax can create tuplestores to contain old and/or new versions of rows affected by a statement. References to these tuplestores are in the TriggerData structure. C triggers can access the tuplestores directly, so they are usable, but they cannot yet be referenced within a SQL statement.
2016-11-04 16:49:50 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Implement syntax for transition tables in AFTER triggers. This is infrastructure for the complete SQL standard feature. No support is included at this point for execution nodes or PLs. The intent is to add that soon. As this patch leaves things, standard syntax can create tuplestores to contain old and/or new versions of rows affected by a statement. References to these tuplestores are in the TriggerData structure. C triggers can access the tuplestores directly, so they are usable, but they cannot yet be referenced within a SQL statement.
2016-11-04 16:49:50 +01:00
</row>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</tbody>
</tgroup>
</table>
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
<para>
Currently, column-specific triggering is supported only for
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>UPDATE</literal> events, and so <structfield>tgattr</structfield> is relevant
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
to be table-wide regardless of what is in <structfield>tgattr</structfield>.
Support SQL-compliant triggers on columns, ie fire only if certain columns are named in the UPDATE's SET list. Note: the schema of pg_trigger has not actually changed; we've just started to use a column that was there all along. catversion bumped anyway so that this commit is included in the history of potentially interesting changes to system catalog contents. Itagaki Takahiro
2009-10-15 00:14:25 +02:00
</para>
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
<note>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
largely redundant with the referenced <link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link> entry.
Improve the handling of SET CONSTRAINTS commands by having them search pg_constraint before searching pg_trigger. This allows saner handling of corner cases; in particular we now say "constraint is not deferrable" rather than "constraint does not exist" when the command is applied to a constraint that's inherently non-deferrable. Per a gripe several months ago from hubert depesz lubaczewski. To make this work without breaking user-defined constraint triggers, we have to add entries for them to pg_constraint. However, in return we can remove the pgconstrname column from pg_constraint, which represents a fairly sizable space savings. I also replaced the tgisconstraint column with tgisinternal; the old meaning of tgisconstraint can now be had by testing for nonzero tgconstraint, while there is no other way to get the old meaning of nonzero tgconstraint, namely that the trigger was internally generated rather than being user-created. In passing, fix an old misstatement in the docs and comments, namely that pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable. Actually, we mark RI action triggers as nondeferrable even when they belong to a nominally deferrable FK constraint. The SET CONSTRAINTS code now relies on that instead of hard-coding a list of exception OIDs.
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.
Fix up foreign-key mechanism so that there is a sound semantic basis for the equality checks it applies, instead of a random dependence on whatever operators might be named "=". The equality operators will now be selected from the opfamily of the unique index that the FK constraint depends on to enforce uniqueness of the referenced columns; therefore they are certain to be consistent with that index's notion of equality. Among other things this should fix the problem noted awhile back that pg_dump may fail for foreign-key constraints on user-defined types when the required operators aren't in the search path. This also means that the former warning condition about "foreign key constraint will require costly sequential scans" is gone: if the comparison condition isn't indexable then we'll reject the constraint entirely. All per past discussions. Along the way, make the RI triggers look into pg_constraint for their information, instead of using pg_trigger.tgargs; and get rid of the always error-prone fixed-size string buffers in ri_triggers.c in favor of building up the RI queries in StringInfo buffers. initdb forced due to columns added to pg_constraint and pg_trigger.
2007-02-14 02:58:58 +01:00
</para>
</note>
Make relhasrules and relhastriggers work like relhasindex, namely we let VACUUM reset them to false rather than trying to clean 'em up during DROP.
2008-11-10 01:49:37 +01:00
<note>
<para>
<literal>pg_class.relhastriggers</literal>
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
must be true if a relation has any triggers in this catalog.
Make relhasrules and relhastriggers work like relhasindex, namely we let VACUUM reset them to false rather than trying to clean 'em up during DROP.
2008-11-10 01:49:37 +01:00
</para>
</note>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
Add catalogs.sgml documentation for text search catalogs.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_config</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this configuration
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_config_map</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
are specified by a text string <structfield>dictinitoption</structfield>,
Add catalogs.sgml documentation for text search catalogs.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_dict</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this dictionary
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_parser</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this parser
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
OID of the parser's headline function (zero if none)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
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
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
described at length in <xref linkend="textsearch"/>.
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</para>
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_ts_template</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
The OID of the namespace that contains this template
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
OID of the template's initialization function (zero if none)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
<sect1 id="catalog-pg-type">
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_type</structname></title>
<indexterm zone="catalog-pg-type">
<primary>pg_type</primary>
</indexterm>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
<para>
More minor updates and copy-editing.
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
More minor updates and copy-editing.
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>.
Reinstate pg_type's typsend and typreceive columns. They don't do much yet, but they're there. Also some editorial work on CREATE TYPE reference page.
2003-05-09 00:19:58 +02:00
A composite type is automatically created for each table in the database, to
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
represent the row structure of the table. It is also possible to create
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
composite types with <command>CREATE TYPE AS</command>.
Add note about pg_stats to pg_statistic entry; add sections for pg_largeobject, pg_listener, pg_rewrite, pg_trigger; miscellaneous small improvements.
2001-10-16 00:47:47 +02:00
</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<table>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_type</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
The OID of the namespace that contains this type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
pg_type has a typnamespace column; system now supports creating types in different namespaces. Also, cleanup work on relation namespace support: drop, alter, rename commands work for tables in non-default namespaces.
2002-03-29 20:06:29 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
The cstring datatype can now be copied, passed around, etc. The typlen value '-2' is used to indicate a variable-width type whose width is computed as strlen(datum)+1. Everything that looks at typlen is updated except for array support, which Joe Conway is working on; at the moment it wouldn't work to try to create an array of cstring.
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.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
-1 indicates a <quote>varlena</quote> type (one that has a length word),
The cstring datatype can now be copied, passed around, etc. The typlen value '-2' is used to indicate a variable-width type whose width is computed as strlen(datum)+1. Everything that looks at typlen is updated except for array support, which Joe Conway is working on; at the moment it wouldn't work to try to create an array of cstring.
2002-08-24 17:00:47 +02:00
-2 indicates a null-terminated C string.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
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.
Reinstate pg_type's typsend and typreceive columns. They don't do much yet, but they're there. Also some editorial work on CREATE TYPE reference page.
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).
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
length would allow pass-by-value.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
<structfield>typtype</structfield> is
<literal>b</literal> for a base type,
<literal>c</literal> for a composite type (e.g., a table's row type),
<literal>d</literal> for a domain,
<literal>e</literal> for an enum type,
Multirange datatypes Multiranges are basically sorted arrays of non-overlapping ranges with set-theoretic operations defined over them. Since v14, each range type automatically gets a corresponding multirange datatype. There are both manual and automatic mechanisms for naming multirange types. Once can specify multirange type name using multirange_type_name attribute in CREATE TYPE.  Otherwise, a multirange type name is generated automatically. If the range type name contains "range" then we change that to "multirange". Otherwise, we add "_multirange" to the end. Implementation of multiranges comes with a space-efficient internal representation format, which evades extra paddings and duplicated storage of oids.  Altogether this format allows fetching a particular range by its index in O(n). Statistic gathering and selectivity estimation are implemented for multiranges. For this purpose, stored multirange is approximated as union range without gaps. This field will likely need improvements in the future. Catversion is bumped. Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0 Author: Paul Jungwirth, revised by me Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
<literal>p</literal> for a pseudo-type,
<literal>r</literal> for a range type, or
<literal>m</literal> for a multirange type.
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
See also <structfield>typrelid</structfield> and
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structfield>typbasetype</structfield>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
casts should be <quote>preferred</quote>.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
See <xref linkend="catalog-typcategory-table"/>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
except the type name, namespace, and OID can be relied on.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
element data type, not the array data type.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Reinstate pg_type's typsend and typreceive columns. They don't do much yet, but they're there. Also some editorial work on CREATE TYPE reference page.
2003-05-09 00:19:58 +02:00
If this is a composite type (see
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<structfield>typtype</structfield>), then this column points to
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
the <link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry that defines the
Update info about relkind and pg_type entries for composite-types patch.
2002-08-28 17:02:55 +02:00
corresponding table. (For a free-standing composite type, the
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-class"><structname>pg_class</structname></link> entry doesn't really represent
Update info about relkind and pg_type entries for composite-types patch.
2002-08-28 17:02:55 +02:00
a table, but it is needed anyway for the type's
doc: Add missing cross-links in system catalog documentation This makes the first mention of a system catalog or view in each paragraph in the system system catalog and view documentation pages hyperlinks, for easier navigation. Also linkify the first mention of pg_hba.conf in pg_hba_file_rules, as that's more specific and easier to spot than the link to the client authentication chapter. Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87mu5xqc11.fsf@wibble.ilmari.org
2020-09-03 13:15:53 +02:00
<link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link> entries to link to.)
Spell and markup checking
2010-08-17 06:37:21 +02:00
Zero for non-composite types.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Support subscripting of arbitrary types, not only arrays. This patch generalizes the subscripting infrastructure so that any data type can be subscripted, if it provides a handler function to define what that means. Traditional variable-length (varlena) arrays all use array_subscript_handler(), while the existing fixed-length types that support subscripting use raw_array_subscript_handler(). It's expected that other types that want to use subscripting notation will define their own handlers. (This patch provides no such new features, though; it only lays the foundation for them.) To do this, move the parser's semantic processing of subscripts (including coercion to whatever data type is required) into a method callback supplied by the handler. On the execution side, replace the ExecEvalSubscriptingRef* layer of functions with direct calls to callback-supplied execution routines. (Thus, essentially no new run-time overhead should be caused by this patch. Indeed, there is room to remove some overhead by supplying specialized execution routines. This patch does a little bit in that line, but more could be done.) Additional work is required here and there to remove formerly hard-wired assumptions about the result type, collation, etc of a SubscriptingRef expression node; and to remove assumptions that the subscript values must be integers. One useful side-effect of this is that we now have a less squishy mechanism for identifying whether a data type is a "true" array: instead of wiring in weird rules about typlen, we can look to see if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this to be bulletproof, we have to forbid user-defined types from using that handler directly; but there seems no good reason for them to do so. This patch also removes assumptions that the number of subscripts is limited to MAXDIM (6), or indeed has any hard-wired limit. That limit still applies to types handled by array_subscript_handler or raw_array_subscript_handler, but to discourage other dependencies on this constant, I've moved it from c.h to utils/array.h. Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov, Peter Eisentraut, Pavel Stehule Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>typsubscript</structfield> <type>regproc</type>
(references <link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.<structfield>oid</structfield>)
</para>
<para>
Subscripting handler function's OID, or zero if this type doesn't
support subscripting. Types that are <quote>true</quote> array
types have <structfield>typsubscript</structfield>
= <function>array_subscript_handler</function>, but other types may
have other handler functions to implement specialized subscripting
behavior.
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
If <structfield>typelem</structfield> is not zero then it
Support subscripting of arbitrary types, not only arrays. This patch generalizes the subscripting infrastructure so that any data type can be subscripted, if it provides a handler function to define what that means. Traditional variable-length (varlena) arrays all use array_subscript_handler(), while the existing fixed-length types that support subscripting use raw_array_subscript_handler(). It's expected that other types that want to use subscripting notation will define their own handlers. (This patch provides no such new features, though; it only lays the foundation for them.) To do this, move the parser's semantic processing of subscripts (including coercion to whatever data type is required) into a method callback supplied by the handler. On the execution side, replace the ExecEvalSubscriptingRef* layer of functions with direct calls to callback-supplied execution routines. (Thus, essentially no new run-time overhead should be caused by this patch. Indeed, there is room to remove some overhead by supplying specialized execution routines. This patch does a little bit in that line, but more could be done.) Additional work is required here and there to remove formerly hard-wired assumptions about the result type, collation, etc of a SubscriptingRef expression node; and to remove assumptions that the subscript values must be integers. One useful side-effect of this is that we now have a less squishy mechanism for identifying whether a data type is a "true" array: instead of wiring in weird rules about typlen, we can look to see if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this to be bulletproof, we have to forbid user-defined types from using that handler directly; but there seems no good reason for them to do so. This patch also removes assumptions that the number of subscripts is limited to MAXDIM (6), or indeed has any hard-wired limit. That limit still applies to types handled by array_subscript_handler or raw_array_subscript_handler, but to discourage other dependencies on this constant, I've moved it from c.h to utils/array.h. Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov, Peter Eisentraut, Pavel Stehule Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
identifies another row in <structname>pg_type</structname>,
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
defining the type yielded by subscripting. This should be zero
if <structfield>typsubscript</structfield> is zero. However, it can
be zero when <structfield>typsubscript</structfield> isn't zero, if the
Support subscripting of arbitrary types, not only arrays. This patch generalizes the subscripting infrastructure so that any data type can be subscripted, if it provides a handler function to define what that means. Traditional variable-length (varlena) arrays all use array_subscript_handler(), while the existing fixed-length types that support subscripting use raw_array_subscript_handler(). It's expected that other types that want to use subscripting notation will define their own handlers. (This patch provides no such new features, though; it only lays the foundation for them.) To do this, move the parser's semantic processing of subscripts (including coercion to whatever data type is required) into a method callback supplied by the handler. On the execution side, replace the ExecEvalSubscriptingRef* layer of functions with direct calls to callback-supplied execution routines. (Thus, essentially no new run-time overhead should be caused by this patch. Indeed, there is room to remove some overhead by supplying specialized execution routines. This patch does a little bit in that line, but more could be done.) Additional work is required here and there to remove formerly hard-wired assumptions about the result type, collation, etc of a SubscriptingRef expression node; and to remove assumptions that the subscript values must be integers. One useful side-effect of this is that we now have a less squishy mechanism for identifying whether a data type is a "true" array: instead of wiring in weird rules about typlen, we can look to see if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this to be bulletproof, we have to forbid user-defined types from using that handler directly; but there seems no good reason for them to do so. This patch also removes assumptions that the number of subscripts is limited to MAXDIM (6), or indeed has any hard-wired limit. That limit still applies to types handled by array_subscript_handler or raw_array_subscript_handler, but to discourage other dependencies on this constant, I've moved it from c.h to utils/array.h. Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov, Peter Eisentraut, Pavel Stehule Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
handler doesn't need <structfield>typelem</structfield> to
determine the subscripting result type.
Note that a <structfield>typelem</structfield> dependency is
considered to imply physical containment of the element type in
this type; so DDL changes on the element type might be restricted
by the presence of this type.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
If <structfield>typarray</structfield> is not zero then it
Support arrays of composite types, including the rowtypes of regular tables and views (but not system catalogs, nor sequences or toast tables). Get rid of the hardwired convention that a type's array type is named exactly "_type", instead using a new column pg_type.typarray to provide the linkage. (It still will be named "_type", though, except in odd corner cases such as maximum-length type names.) Along the way, make tracking of owner and schema dependencies for types more uniform: a type directly created by the user has these dependencies, while a table rowtype or auto-generated array type does not have them, but depends on its parent object instead. David Fetter, Andrew Dunstan, Tom Lane
2007-05-11 19:57:14 +02:00
identifies another row in <structname>pg_type</structname>, which
is the <quote>true</quote> array type having this type as element
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Reinstate pg_type's typsend and typreceive columns. They don't do much yet, but they're there. Also some editorial work on CREATE TYPE reference page.
2003-05-09 00:19:58 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Input conversion function (binary format), or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Reinstate pg_type's typsend and typreceive columns. They don't do much yet, but they're there. Also some editorial work on CREATE TYPE reference page.
2003-05-09 00:19:58 +02:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Output conversion function (binary format), or zero if none
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Type modifier input function, or zero if type does not support modifiers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Type modifier output function, or zero to use the standard format
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Support type modifiers for user-defined types, and pull most knowledge about typmod representation for standard types out into type-specific typmod I/O functions. Teodor Sigaev, with some editorialization by Tom Lane.
2006-12-30 22:21:56 +01:00
</row>
Add hooks for type-specific calculation of ANALYZE statistics. Idea and coding by Mark Cave-Ayland, some kibitzing by Tom Lane. initdb forced due to new column in pg_type.
2004-02-13 00:41:04 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
Custom <xref linkend="sql-analyze"/> function,
or zero to use the standard function
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add hooks for type-specific calculation of ANALYZE statistics. Idea and coding by Mark Cave-Ayland, some kibitzing by Tom Lane. initdb forced due to new column in pg_type.
2004-02-13 00:41:04 +01:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<productname>PostgreSQL</productname>.
Replace pg_attribute.attisinherited with attislocal and attinhcount columns, to allow more correct behavior in multiple-inheritance cases. Patch by Alvaro Herrera, review by Tom Lane.
2002-09-22 21:42:52 +02:00
When multiple values are stored consecutively, such
Rewrite system catalog documentation man page in DocBook with more recent information.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<para><literal>c</literal> = <type>char</type> alignment, i.e., no alignment needed.</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<para><literal>s</literal> = <type>short</type> alignment (2 bytes on most machines).</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<para><literal>i</literal> = <type>int</type> alignment (4 bytes on most machines).</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
</itemizedlist>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
The cstring datatype can now be copied, passed around, etc. The typlen value '-2' is used to indicate a variable-width type whose width is computed as strlen(datum)+1. Everything that looks at typlen is updated except for array support, which Joe Conway is working on; at the moment it wouldn't work to try to create an array of cstring.
2002-08-24 17:00:47 +02:00
<structfield>typstorage</structfield> tells for varlena
Rewrite system catalog documentation man page in DocBook with more recent information.
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.
Allow ALTER TYPE to change some properties of a base type. Specifically, this patch allows ALTER TYPE to: * Change the default TOAST strategy for a toastable base type; * Promote a non-toastable type to toastable; * Add/remove binary I/O functions for a type; * Add/remove typmod I/O functions for a type; * Add/remove a custom ANALYZE statistics functions for a type. The first of these can be done by the type's owner; all the others require superuser privilege since misuse could cause problems. The main motivation for this patch is to allow extensions to upgrade the feature sets of their data types, so the set of alterable properties is biased towards that use-case. However it's also true that changing some other properties would be a lot harder, as they get baked into physical storage and/or stored expressions that depend on the type. Along the way, refactor GenerateTypeDependencies() to make it easier to call, refactor DefineType's volatility checks so they can be shared by AlterType, and teach typcache.c that it might have to reload data from the type's pg_type row, a scenario it never handled before. Also rearrange alter_type.sgml a bit for clarity (put the composite-type operations together). Tomas Vondra and Tom Lane Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development
2020-03-06 18:19:29 +01:00
Possible values are:
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<itemizedlist>
<listitem>
Allow ALTER TYPE to change some properties of a base type. Specifically, this patch allows ALTER TYPE to: * Change the default TOAST strategy for a toastable base type; * Promote a non-toastable type to toastable; * Add/remove binary I/O functions for a type; * Add/remove typmod I/O functions for a type; * Add/remove a custom ANALYZE statistics functions for a type. The first of these can be done by the type's owner; all the others require superuser privilege since misuse could cause problems. The main motivation for this patch is to allow extensions to upgrade the feature sets of their data types, so the set of alterable properties is biased towards that use-case. However it's also true that changing some other properties would be a lot harder, as they get baked into physical storage and/or stored expressions that depend on the type. Along the way, refactor GenerateTypeDependencies() to make it easier to call, refactor DefineType's volatility checks so they can be shared by AlterType, and teach typcache.c that it might have to reload data from the type's pg_type row, a scenario it never handled before. Also rearrange alter_type.sgml a bit for clarity (put the composite-type operations together). Tomas Vondra and Tom Lane Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
<para>
Allow ALTER TYPE to change some properties of a base type. Specifically, this patch allows ALTER TYPE to: * Change the default TOAST strategy for a toastable base type; * Promote a non-toastable type to toastable; * Add/remove binary I/O functions for a type; * Add/remove typmod I/O functions for a type; * Add/remove a custom ANALYZE statistics functions for a type. The first of these can be done by the type's owner; all the others require superuser privilege since misuse could cause problems. The main motivation for this patch is to allow extensions to upgrade the feature sets of their data types, so the set of alterable properties is biased towards that use-case. However it's also true that changing some other properties would be a lot harder, as they get baked into physical storage and/or stored expressions that depend on the type. Along the way, refactor GenerateTypeDependencies() to make it easier to call, refactor DefineType's volatility checks so they can be shared by AlterType, and teach typcache.c that it might have to reload data from the type's pg_type row, a scenario it never handled before. Also rearrange alter_type.sgml a bit for clarity (put the composite-type operations together). Tomas Vondra and Tom Lane Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development
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
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>pg_class.reltoastrelid</literal>).
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
</listitem>
<listitem>
Allow ALTER TYPE to change some properties of a base type. Specifically, this patch allows ALTER TYPE to: * Change the default TOAST strategy for a toastable base type; * Promote a non-toastable type to toastable; * Add/remove binary I/O functions for a type; * Add/remove typmod I/O functions for a type; * Add/remove a custom ANALYZE statistics functions for a type. The first of these can be done by the type's owner; all the others require superuser privilege since misuse could cause problems. The main motivation for this patch is to allow extensions to upgrade the feature sets of their data types, so the set of alterable properties is biased towards that use-case. However it's also true that changing some other properties would be a lot harder, as they get baked into physical storage and/or stored expressions that depend on the type. Along the way, refactor GenerateTypeDependencies() to make it easier to call, refactor DefineType's volatility checks so they can be shared by AlterType, and teach typcache.c that it might have to reload data from the type's pg_type row, a scenario it never handled before. Also rearrange alter_type.sgml a bit for clarity (put the composite-type operations together). Tomas Vondra and Tom Lane Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development
2020-03-06 18:19:29 +01:00
<para>
<literal>m</literal> (main): Values can be compressed and stored
inline.
</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
Allow ALTER TYPE to change some properties of a base type. Specifically, this patch allows ALTER TYPE to: * Change the default TOAST strategy for a toastable base type; * Promote a non-toastable type to toastable; * Add/remove binary I/O functions for a type; * Add/remove typmod I/O functions for a type; * Add/remove a custom ANALYZE statistics functions for a type. The first of these can be done by the type's owner; all the others require superuser privilege since misuse could cause problems. The main motivation for this patch is to allow extensions to upgrade the feature sets of their data types, so the set of alterable properties is biased towards that use-case. However it's also true that changing some other properties would be a lot harder, as they get baked into physical storage and/or stored expressions that depend on the type. Along the way, refactor GenerateTypeDependencies() to make it easier to call, refactor DefineType's volatility checks so they can be shared by AlterType, and teach typcache.c that it might have to reload data from the type's pg_type row, a scenario it never handled before. Also rearrange alter_type.sgml a bit for clarity (put the composite-type operations together). Tomas Vondra and Tom Lane Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
</itemizedlist>
Allow ALTER TYPE to change some properties of a base type. Specifically, this patch allows ALTER TYPE to: * Change the default TOAST strategy for a toastable base type; * Promote a non-toastable type to toastable; * Add/remove binary I/O functions for a type; * Add/remove typmod I/O functions for a type; * Add/remove a custom ANALYZE statistics functions for a type. The first of these can be done by the type's owner; all the others require superuser privilege since misuse could cause problems. The main motivation for this patch is to allow extensions to upgrade the feature sets of their data types, so the set of alterable properties is biased towards that use-case. However it's also true that changing some other properties would be a lot harder, as they get baked into physical storage and/or stored expressions that depend on the type. Along the way, refactor GenerateTypeDependencies() to make it easier to call, refactor DefineType's volatility checks so they can be shared by AlterType, and teach typcache.c that it might have to reload data from the type's pg_type row, a scenario it never handled before. Also rearrange alter_type.sgml a bit for clarity (put the composite-type operations together). Tomas Vondra and Tom Lane Discussion: https://postgr.es/m/20200228004440.b23ein4qvmxnlpht@development
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).
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para></entry>
</row>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<structfield>typnotnull</structfield> represents a not-null
Spell and markup checking
2010-08-17 06:37:21 +02:00
constraint on a type. Used for domains only.
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
</para></entry>
</row>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Do a round of copy-editing for the system catalog chapter. In particular, consistently capitalize the content of the "Description" column but do not include a terminating period, as is the convention elsewhere in the docs. Also, remove the "References" column from catalog that do not have any referencing columns, for the sake of brevity. Make various other SGML and grammar fixes.
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
one is based on. Zero if this type is not a domain.
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
</para></entry>
</row>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Domains use <structfield>typtypmod</structfield> to record the <literal>typmod</literal>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
to be applied to their base type (-1 if base type does not use a
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>typmod</literal>). -1 if this type is not a domain.
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
</para></entry>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<structfield>typndims</structfield> is the number of array dimensions
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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).
Spell and markup checking
2010-08-17 06:37:21 +02:00
Zero for types other than domains over array types.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
</row>
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
<structfield>typcollation</structfield> specifies the collation
Assorted editing for collation documentation. I made a pass over this to familiarize myself with the feature, and found some things that could be improved.
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.
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
2011-02-08 22:04:18 +01:00
</para></entry>
</row>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
If <structfield>typdefaultbin</structfield> is not null, it is the
Install a data-type-based solution for protecting pg_get_expr(). Since the code underlying pg_get_expr() is not secure against malformed input, and can't practically be made so, we need to prevent miscreants from feeding arbitrary data to it. We can do this securely by declaring pg_get_expr() to take a new datatype "pg_node_tree" and declaring the system catalog columns that hold nodeToString output to be of that type. There is no way at SQL level to create a non-null value of type pg_node_tree. Since the backend-internal operations that fill those catalog columns operate below the SQL level, they are oblivious to the datatype relabeling and don't need any changes.
2010-09-03 03:34:55 +02:00
<function>nodeToString()</function>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
representation of a default expression for the type. This is
Spell and markup checking
2010-08-17 06:37:21 +02:00
only used for domains.
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
</para></entry>
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Install a data-type-based solution for protecting pg_get_expr(). Since the code underlying pg_get_expr() is not secure against malformed input, and can't practically be made so, we need to prevent miscreants from feeding arbitrary data to it. We can do this securely by declaring pg_get_expr() to take a new datatype "pg_node_tree" and declaring the system catalog columns that hold nodeToString output to be of that type. There is no way at SQL level to create a non-null value of type pg_node_tree. Since the backend-internal operations that fill those catalog columns operate below the SQL level, they are oblivious to the datatype relabeling and don't need any changes.
2010-09-03 03:34:55 +02:00
the type's default value, which can be fed to the type's input
Spell and markup checking
2010-08-17 06:37:21 +02:00
converter to produce a constant.
Fix handling of pg_type.typdefault per bug report from Dave Blasby. If there's anyone out there who's actually using datatype-defined default values, this will be an incompatible change in behavior ... but the old behavior was so broken that I doubt anyone was using it.
2001-09-06 04:07:42 +02:00
</para></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Refactor documentation about privileges to centralize the info. Expand section 5.6 "Privileges" to include the full definition of each privilege type, and an explanation of aclitem privilege displays, along with some helpful summary tables. Most of this material came out of the GRANT reference page, although some of it is new. Adjust a bunch of links that were pointing to GRANT to point to 5.6. Fabien Coelho and Tom Lane, reviewed by Bradley DeJong Discussion: https://postgr.es/m/alpine.DEB.2.21.1807311735200.20743@lancre
2018-12-03 17:40:49 +01:00
Access privileges; see <xref linkend="ddl-priv"/> for details
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
</row>
Rewrite system catalog documentation man page in DocBook with more recent information.
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
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="catalog-typcategory-table"/> lists the system-defined values
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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">
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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
Fix some SGML-compiler warnings on -wxml mode.
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>
Further review of range-types patch. Lots of documentation cleanup today, and still more type_sanity tests.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
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>
Create a new type category for "internal use" types. Historically we've put type "char" into the S (String) typcategory, although calling it a string is a stretch considering it can only store one byte. (In our actual usage, it's more like an enum.) This choice now seems wrong in view of the special heuristics that parse_func.c and parse_coerce.c have for TYPCATEGORY_STRING: it's not a great idea for "char" to have those preferential casting behaviors. Worse than that, recent patches inventing special-purpose types like pg_node_tree have assigned typcategory S to those types, meaning they also get preferential casting treatment that's designed on the assumption that they can hold arbitrary text. To fix, invent a new category TYPCATEGORY_INTERNAL for internal-use types, and assign that to all these types. I used code 'Z' for lack of a better idea ('I' was already taken). This change breaks one query in psql/describe.c, which now needs to explicitly cast a catalog "char" column to text before concatenating it with an undecorated literal. Also, a test case in contrib/citext now needs an explicit cast to convert citext to "char". Since the point of this change is to not have "char" be a surprisingly-available cast target, these breakages seem OK. Per report from Ian Campbell. Discussion: https://postgr.es/m/2216388.1638480141@sss.pgh.pa.us
2021-12-11 20:10:51 +01:00
<row>
<entry><literal>Z</literal></entry>
<entry>Internal-use types</entry>
</row>
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType() with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
2008-07-30 19:05:05 +02:00
</tbody>
</tgroup>
</table>
Use <sect1> rather than <section> to simplify formatting.
2001-11-09 00:44:01 +01:00
</sect1>
Document all the system views created by initdb (several of these were never documented anywhere, sigh). Centralize the detailed documentation of system views into catalogs.sgml, and provide cross-references.
2003-10-18 00:38:20 +02:00
Put pg_user_mapping section into the right (alphabetical) order.
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<title><structname>pg_user_mapping</structname> Columns</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
</row>
</thead>
<tbody>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
doc: Add oid columns to system catalog documentation Karl O. Pinc and Jeff Davis
2012-12-15 06:42:47 +01:00
</row>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Doc: consistently identify OID catalog columns that can be zero. Not all OID-reference columns that can contain zeroes (indicating "no reference") were explicitly marked in catalogs.sgml. Fix that, and try to make the style a little more consistent while at it --- for example, consistently write "zero" not "0" for these cases. Joel Jacobson and Tom Lane Discussion: https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com
2021-02-02 22:15:29 +01:00
OID of the local role being mapped, or zero if the user mapping is public
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
The OID of the foreign server that contains this mapping
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
</row>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
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>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
User mapping specific options, as <quote>keyword=value</quote> strings
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</chapter>