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

9276 lines
303 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
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
are always SQL commands to do that. (For example, <command>CREATE
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
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
particularly esoteric operations, such as adding index access methods.
</para>
<sect1 id="catalogs-overview">
<title>Overview</title>
<para>
<xref linkend="catalog-table"> lists the system catalogs.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>index access methods</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-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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>access method support procedures</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-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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02: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>
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>
<entry><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link></entry>
<entry>collations (locale information)</entry>
</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>
<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>
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>
<entry><link linkend="catalog-pg-pltemplate"><structname>pg_pltemplate</structname></link></entry>
<entry>template data for procedural languages</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>
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>
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-rewrite"><structname>pg_rewrite</structname></link></entry>
<entry>query rewrite rules</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +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>
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>
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>
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
in <structname>pg_proc</structname>. The <structname>pg_proc</structname>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
entry carries the aggregate's name, input and output data types, 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
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_aggregate</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>aggfnoid</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structname>pg_proc</structname> OID of the aggregate function</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><structfield>aggtransfn</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Transition function</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>aggfinalfn</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry>Final function (zero if none)</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
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>
<entry><structfield>aggsortop</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</literal></entry>
<entry>Associated sort operator (zero if none)</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><structfield>aggtranstype</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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
<entry>Data type of the aggregate function's internal transition (state) data</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
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>
<entry><structfield>aggtransspace</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<entry>Approximate average size (in bytes) of the transition state
data, or zero to use a default estimate</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><structfield>agginitval</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>text</type></entry>
<entry></entry>
<entry>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
</tbody>
</tgroup>
</table>
<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
New aggregate functions are registered with the <xref
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
linkend="sql-createaggregate">
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
command. See <xref linkend="xaggr"> for more information about
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>
Write some real documentation about the index access method API.
2005-02-13 04:04:15 +01:00
The catalog <structname>pg_am</structname> stores information about index
access methods. There is one row for each index access method supported by
the system. The contents of this catalog are discussed in detail in
<xref linkend="indexam">.
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_am</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amname</structfield></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
<entry><type>name</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Name of the access method</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amstrategies</structfield></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
<entry><type>int2</type></entry>
<entry></entry>
Set pg_am.amstrategies to zero for index AMs that don't have fixed operator strategy numbers, ie, GiST and GIN. This is almost cosmetic enough to not need a catversion bump, but since the opr_sanity regression test has to change in sync with the catalog entry, I figured I'd better do one.
2006-12-18 19:56:29 +01:00
<entry>Number of operator strategies for this access method,
or zero if access method does not have a fixed set of operator
strategies</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amsupport</structfield></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
<entry><type>int2</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Number of support routines for this access method</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>
Simplify pg_am representation of ordering-capable access methods: provide just a boolean 'amcanorder', instead of fields that specify the sort operator strategy numbers. We have decided to require ordering-capable AMs to use btree-compatible strategy numbers, so the old fields are overkill (and indeed misleading about what's allowed).
2007-01-21 00:13:01 +01:00
<entry><structfield>amcanorder</structfield></entry>
<entry><type>bool</type></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
<entry></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
<entry>Does the access method support ordered scans sorted by the
indexed column's value?</entry>
</row>
<row>
<entry><structfield>amcanorderbyop</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Does the access method support ordered scans sorted by the result
of an operator on the indexed column?</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>
Add a new column to pg_am to specify whether an index AM supports backward scanning; GiST and GIN do not, and it seems like too much trouble to make them do so. By teaching ExecSupportsBackwardScan() about this restriction, we ensure that the planner will protect a scroll cursor from the problem by adding a Materialize node. In passing, fix another longstanding bug in the same area: backwards scan of a plan with set-returning functions in the targetlist did not work either, since the TupFromTlist expansion code pays no attention to direction (and has no way to run a SRF backwards anyway). Again the fix is to make ExecSupportsBackwardScan check this restriction. Also adjust the index AM API specification to note that mark/restore support is unnecessary if the AM can't produce ordered output.
2008-10-18 00:10:30 +02:00
<row>
<entry><structfield>amcanbackward</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Does the access method support backward scanning?</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amcanunique</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Does the access method support unique indexes?</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amcanmulticol</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Does the access method support multicolumn indexes?</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>
Change the planner to allow indexscan qualification clauses to use nonconsecutive columns of a multicolumn index, as per discussion around mid-May (pghackers thread "Best way to scan on-disk bitmaps"). This turns out to require only minimal changes in btree, and so far as I can see none at all in GiST. btcostestimate did need some work, but its original assumption that index selectivity == heap selectivity was quite bogus even before this.
2005-06-14 01:14:49 +02:00
<row>
<entry><structfield>amoptionalkey</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Does the access method support a scan without any constraint
for the first index column?</entry>
</row>
Teach btree to handle ScalarArrayOpExpr quals natively. This allows "indexedcol op ANY(ARRAY[...])" conditions to be used in plain indexscans, and particularly in index-only scans.
2011-10-16 21:39:24 +02:00
<row>
<entry><structfield>amsearcharray</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Does the access method support <literal>ScalarArrayOpExpr</> searches?</entry>
</row>
Make 'col IS NULL' clauses be indexable conditions. Teodor Sigaev, with some kibitzing from Tom Lane.
2007-04-07 00:33:43 +02:00
<row>
<entry><structfield>amsearchnulls</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Does the access method support <literal>IS NULL</>/<literal>NOT NULL</> searches?</entry>
Make 'col IS NULL' clauses be indexable conditions. Teodor Sigaev, with some kibitzing from Tom Lane.
2007-04-07 00:33:43 +02:00
</row>
Clean up API for ambulkdelete/amvacuumcleanup as per today's discussion. This formulation requires every AM to provide amvacuumcleanup, unlike before, but it's surely a whole lot cleaner. Also, add an 'amstorage' column to pg_am so that we can get rid of hardwired knowledge in DefineOpClass().
2006-05-03 00:25:10 +02:00
<row>
<entry><structfield>amstorage</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Can index storage data type differ from column data type?</entry>
</row>
<row>
<entry><structfield>amclusterable</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
Spellchecking and such
2006-10-23 20:10:32 +02:00
<entry>Can an index of this type be clustered on?</entry>
Clean up API for ambulkdelete/amvacuumcleanup as per today's discussion. This formulation requires every AM to provide amvacuumcleanup, unlike before, but it's surely a whole lot cleaner. Also, add an 'amstorage' column to pg_am so that we can get rid of hardwired knowledge in DefineOpClass().
2006-05-03 00:25:10 +02:00
</row>
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
<row>
<entry><structfield>ampredlocks</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Does an index of this type manage fine-grained predicate locks?</entry>
</row>
Change hash indexes to store only the hash code rather than the whole indexed value. This means that hash index lookups are always lossy and have to be rechecked when the heap is visited; however, the gain in index compactness outweighs this when the indexed values are wide. Also, we only need to perform datatype comparisons when the hash codes match exactly, rather than for every entry in the hash bucket; so it could also win for datatypes that have expensive comparison functions. A small additional win is gained by keeping hash index pages sorted by hash code and using binary search to reduce the number of index tuples we have to look at. Xiao Meng This commit also incorporates Zdenek Kotala's patch to isolate hash metapages and hash bitmaps a bit better from the page header datastructures.
2008-09-15 20:43:41 +02:00
<row>
<entry><structfield>amkeytype</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>Type of data stored in index, or zero if not a fixed type</entry>
</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>
First steps towards index scans with heap access decoupled from index access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
2005-03-28 01:53:05 +02:00
<entry><structfield>aminsert</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
First steps towards index scans with heap access decoupled from index access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
2005-03-28 01:53:05 +02:00
<entry><quote>Insert this tuple</quote> function</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>
First steps towards index scans with heap access decoupled from index access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
2005-03-28 01:53:05 +02:00
<entry><structfield>ambeginscan</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Create core infrastructure for KNNGIST. This is a heavily revised version of builtin_knngist_core-0.9. The ordering operators are no longer mixed in with actual quals, which would have confused not only humans but significant parts of the planner. Instead, ordering operators are carried separately throughout planning and execution. Since the API for ambeginscan and amrescan functions had to be changed anyway, this commit takes the opportunity to rationalize that a bit. RelationGetIndexScan no longer forces a premature index_rescan call; instead, callers of index_beginscan must call index_rescan too. Aside from making the AM-side initialization logic a bit less peculiar, this has the advantage that we do not make a useless extra am_rescan call when there are runtime key values. AMs formerly could not assume that the key values passed to amrescan were actually valid; now they can. Teodor Sigaev and Tom Lane
2010-12-03 02:50:48 +01:00
<entry><quote>Prepare for index scan</quote> function</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>
First steps towards index scans with heap access decoupled from index access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
2005-03-28 01:53:05 +02:00
<entry><structfield>amgettuple</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Teach the planner to support index access methods that only implement amgettuple or only implement amgetbitmap, instead of the former assumption that every AM supports both APIs. Extracted with minor editorialization from Teodor's fast-GIN-insert patch; whatever becomes of that, this seems like a simple and reasonable generalization of the index AM interface spec.
2009-03-06 00:06:45 +01:00
<entry><quote>Next valid tuple</quote> function, or zero if none</entry>
First steps towards index scans with heap access decoupled from index access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
2005-03-28 01:53:05 +02:00
</row>
<row>
Replace "amgetmulti" AM functions with "amgetbitmap", in which the whole indexscan always occurs in one call, and the results are returned in a TIDBitmap instead of a limited-size array of TIDs. This should improve speed a little by reducing AM entry/exit overhead, and it is necessary infrastructure if we are ever to support bitmap indexes. In an only slightly related change, add support for TIDBitmaps to preserve (somewhat lossily) the knowledge that particular TIDs reported by an index need to have their quals rechecked when the heap is visited. This facility is not really used yet; we'll need to extend the forced-recheck feature to plain indexscans before it's useful, and that hasn't been coded yet. The intent is to use it to clean up 8.3's horrid @@@ kluge for text search with weighted queries. There might be other uses in future, but that one alone is sufficient reason. Heikki Linnakangas, with some adjustments by me.
2008-04-11 00:25:26 +02:00
<entry><structfield>amgetbitmap</structfield></entry>
First steps towards index scans with heap access decoupled from index access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
2005-03-28 01:53:05 +02:00
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Teach the planner to support index access methods that only implement amgettuple or only implement amgetbitmap, instead of the former assumption that every AM supports both APIs. Extracted with minor editorialization from Teodor's fast-GIN-insert patch; whatever becomes of that, this seems like a simple and reasonable generalization of the index AM interface spec.
2009-03-06 00:06:45 +01:00
<entry><quote>Fetch all valid tuples</quote> function, or zero if none</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amrescan</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Create core infrastructure for KNNGIST. This is a heavily revised version of builtin_knngist_core-0.9. The ordering operators are no longer mixed in with actual quals, which would have confused not only humans but significant parts of the planner. Instead, ordering operators are carried separately throughout planning and execution. Since the API for ambeginscan and amrescan functions had to be changed anyway, this commit takes the opportunity to rationalize that a bit. RelationGetIndexScan no longer forces a premature index_rescan call; instead, callers of index_beginscan must call index_rescan too. Aside from making the AM-side initialization logic a bit less peculiar, this has the advantage that we do not make a useless extra am_rescan call when there are runtime key values. AMs formerly could not assume that the key values passed to amrescan were actually valid; now they can. Teodor Sigaev and Tom Lane
2010-12-03 02:50:48 +01:00
<entry><quote>(Re)start index scan</quote> function</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amendscan</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Create core infrastructure for KNNGIST. This is a heavily revised version of builtin_knngist_core-0.9. The ordering operators are no longer mixed in with actual quals, which would have confused not only humans but significant parts of the planner. Instead, ordering operators are carried separately throughout planning and execution. Since the API for ambeginscan and amrescan functions had to be changed anyway, this commit takes the opportunity to rationalize that a bit. RelationGetIndexScan no longer forces a premature index_rescan call; instead, callers of index_beginscan must call index_rescan too. Aside from making the AM-side initialization logic a bit less peculiar, this has the advantage that we do not make a useless extra am_rescan call when there are runtime key values. AMs formerly could not assume that the key values passed to amrescan were actually valid; now they can. Teodor Sigaev and Tom Lane
2010-12-03 02:50:48 +01:00
<entry><quote>Clean up after index scan</quote> function</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ammarkpos</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><quote>Mark current scan position</quote> function</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amrestrpos</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><quote>Restore marked scan position</quote> function</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ambuild</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><quote>Build new index</quote> function</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>
Remove pg_am.amindexnulls. The only use we have had for amindexnulls is in determining whether an index is safe to cluster on; but since the addition of the amclusterable flag, that usage is pretty redundant. In passing, clean up assorted sloppiness from the last patch that touched pg_am.h: Natts_pg_am was wrong, and ambuildempty was not documented.
2011-01-08 22:08:05 +01:00
<row>
<entry><structfield>ambuildempty</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry><quote>Build empty index</quote> function</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ambulkdelete</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Bulk-delete function</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>
More infrastructure for btree compaction project. Tree-traversal code now knows what to do upon hitting a dead page (in theory anyway, it's untested...). Add a post-VACUUM-cleanup entry point for index AMs, to provide a place for dead-page scavenging to happen. Also, fix oversight that broke btpo_prev links in temporary indexes. initdb forced due to additions in pg_am.
2003-02-22 01:45:05 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amvacuumcleanup</structfield></entry>
More infrastructure for btree compaction project. Tree-traversal code now knows what to do upon hitting a dead page (in theory anyway, it's untested...). Add a post-VACUUM-cleanup entry point for index AMs, to provide a place for dead-page scavenging to happen. Also, fix oversight that broke btpo_prev links in temporary indexes. initdb forced due to additions in pg_am.
2003-02-22 01:45:05 +01:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Post-<command>VACUUM</command> cleanup function</entry>
More infrastructure for btree compaction project. Tree-traversal code now knows what to do upon hitting a dead page (in theory anyway, it's untested...). Add a post-VACUUM-cleanup entry point for index AMs, to provide a place for dead-page scavenging to happen. Also, fix oversight that broke btpo_prev links in temporary indexes. initdb forced due to additions in pg_am.
2003-02-22 01:45:05 +01:00
</row>
Replace simple constant pg_am.amcanreturn with an AM support function. The need for this was debated when we put in the index-only-scan feature, but at the time we had no near-term expectation of having AMs that could support such scans for only some indexes; so we kept it simple. However, the SP-GiST AM forces the issue, so let's fix it. This patch only installs the new API; no behavior actually changes.
2011-12-18 21:49:00 +01:00
<row>
<entry><structfield>amcanreturn</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>Function to check whether index supports index-only scans,
or zero if none</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amcostestimate</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Function to estimate cost of an index scan</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>
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>
<entry><structfield>amoptions</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Spellchecking and such
2006-10-23 20:10:32 +02:00
<entry>Function to parse and validate <structfield>reloptions</> for an index</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>
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>
</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
member can be either a <firstterm>search</> operator or an
<firstterm>ordering</> 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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_amop</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
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><structfield>amopfamily</structfield></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
<entry><type>oid</type></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><literal><link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.oid</literal></entry>
<entry>The operator family this entry is for</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>
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><structfield>amoplefttype</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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>Left-hand input data type of operator</entry>
</row>
<row>
<entry><structfield>amoprighttype</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>Right-hand input data type of operator</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amopstrategy</structfield></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
<entry><type>int2</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Operator strategy number</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>
<entry><structfield>amoppurpose</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>Operator purpose, either <literal>s</> for search or
<literal>o</> for ordering</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amopopr</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>OID of the operator</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>
<entry><structfield>amopmethod</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
<entry>Index access method operator family is for</entry>
</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>
<entry><structfield>amopsortfamily</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.oid</literal></entry>
<entry>The btree operator family this entry sorts according to, if an
ordering operator; zero if a search operator</entry>
</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>
A <quote>search</> operator entry indicates that an index of this operator
family can be searched to find all rows satisfying
<literal>WHERE</>
<replaceable>indexed_column</>
<replaceable>operator</>
<replaceable>constant</>.
Obviously, such an operator must return boolean, and its left-hand input
type must match the index's column data type.
</para>
<para>
An <quote>ordering</> operator entry indicates that an index of this
operator family can be scanned to return rows in the order represented by
<literal>ORDER BY</>
<replaceable>indexed_column</>
<replaceable>operator</>
<replaceable>constant</>.
Such an operator could return any sortable data type, though again
its left-hand input type must match the index's column data type.
The exact semantics of the <literal>ORDER BY</> are specified by the
<structfield>amopsortfamily</structfield> column, which must reference
a btree operator family for the operator's result type.
</para>
<note>
<para>
At present, it's assumed that the sort order for an ordering operator
is the default for the referenced opfamily, i.e., <literal>ASC NULLS
LAST</>. This might someday be relaxed by adding additional columns
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>
An entry's <structfield>amopmethod</> must match the
<structname>opfmethod</> of its containing operator family (including
<structfield>amopmethod</> here is an intentional denormalization of the
catalog structure for performance reasons). Also,
<structfield>amoplefttype</> and <structfield>amoprighttype</> must match
the <structfield>oprleft</> and <structfield>oprright</> fields of the
referenced <structname>pg_operator</> entry.
</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
support procedures associated with access method operator families. There
is one row for each support procedure 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>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
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><structfield>amprocfamily</structfield></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
<entry><type>oid</type></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><literal><link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.oid</literal></entry>
<entry>The operator family this entry is for</entry>
</row>
<row>
<entry><structfield>amproclefttype</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>Left-hand input data type of associated operator</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>
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><structfield>amprocrighttype</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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>Right-hand input data type of associated operator</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amprocnum</structfield></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
<entry><type>int2</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Support procedure number</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>amproc</structfield></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
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>OID of the procedure</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
<structfield>amproclefttype</> and <structfield>amprocrighttype</> fields
is that they identify the left and right input types of the operator(s)
that a particular support procedure supports. For some access methods
these match the input data type(s) of the support procedure itself, for
others not. There is a notion of <quote>default</> support procedures for
an index, which are those with <structfield>amproclefttype</> and
<structfield>amprocrighttype</> both equal to the index opclass's
<structfield>opcintype</>.
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_attrdef</structname> stores column default values. The main information
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
about columns is stored in <structname>pg_attribute</structname>
(see below). Only columns that explicitly specify a default value
(when the table is created or the column is added) will have an
entry here.
</para>
<table>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_attrdef</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>adrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>The table this column belongs to</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>adnum</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
Update obsolete examples of error messages; various other minor editing.
2003-09-13 00:17:24 +02:00
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></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
<entry>The number of the column</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><structfield>adbin</structfield></entry>
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
<entry><type>pg_node_tree</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The internal representation of the column default value</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><structfield>adsrc</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>text</type></entry>
<entry></entry>
<entry>A human-readable representation of the default value</entry>
</row>
</tbody>
</tgroup>
</table>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<para>
The <structfield>adsrc</structfield> field is historical, and is best
not used, because it does not track outside changes that might affect
the representation of the default value. Reverse-compiling the
<structfield>adbin</structfield> field (with <function>pg_get_expr</> for
example) is a better way to display the default value.
</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
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
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
indexes, and indeed all objects that have <structname>pg_class</structname>
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_attribute</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>The table this column belongs to</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The column name</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><structfield>atttypid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>The data type of this column</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attstattarget</structfield></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
<entry><type>int4</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></entry>
<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
<structfield>attstattarget</structfield> controls the level of detail
of statistics accumulated for this column by
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-analyze">.
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
A zero value indicates that no statistics should be collected.
Instead of having a configure-time DEFAULT_ATTSTATTARGET, store -1 in attstattarget to indicate 'use the default'. The default is now a GUC variable default_statistics_target, and so may be changed on the fly. Along the way we gain the ability to have pg_dump dump the per-column statistics target when it's not the default. Patch by Neil Conway, with some kibitzing from Tom Lane.
2002-07-31 19:19:54 +02:00
A negative value says to use the system default statistics target.
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The exact meaning of positive values is data type-dependent.
For scalar data types, <structfield>attstattarget</structfield>
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
is both the target number of <quote>most common values</quote>
Spell and markup checking
2010-08-17 06:37:21 +02:00
to collect, and the target number of histogram bins to create.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attlen</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
<entry></entry>
<entry>
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
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attnum</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
<entry></entry>
<entry>
The number of the column. Ordinary columns are numbered from 1
up. System columns, such as <structfield>oid</structfield>,
Spell and markup checking
2010-08-17 06:37:21 +02:00
have (arbitrary) negative numbers.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attndims</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int4</type></entry>
<entry></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
<entry>
Clean up wrong, misleading, or obsolete documentation about array types, particularly in the CREATE TYPE reference page. Fix some other errors in the CREATE TYPE page, too.
2001-11-03 22:42:47 +01:00
Number of dimensions, if the column is an array type; otherwise 0.
(Presently, the number of dimensions of an array is not enforced,
Spell and markup checking
2010-08-17 06:37:21 +02:00
so any nonzero value effectively means <quote>it's an array</>.)
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
</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><structfield>attcacheoff</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int4</type></entry>
<entry></entry>
<entry>
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
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>atttypmod</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int4</type></entry>
<entry></entry>
<entry>
<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.
Spell and markup checking
2010-08-17 06:37:21 +02:00
The value will generally be -1 for types that do not need <structfield>atttypmod</>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attbyval</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
A copy of <literal>pg_type.typbyval</> of this column's type
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attstorage</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Normally a copy of <literal>pg_type.typstorage</> of this
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attalign</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
A copy of <literal>pg_type.typalign</> of this column's type
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attnotnull</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
This represents a not-null constraint. It is possible to
Spell and markup checking
2010-08-17 06:37:21 +02:00
change this column to enable or disable the constraint.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>atthasdef</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
This column has a default value, in which case there will be a
corresponding entry in the <structname>pg_attrdef</structname>
Spell and markup checking
2010-08-17 06:37:21 +02:00
catalog that actually defines the value.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attisdropped</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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.
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
</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attislocal</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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.
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
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>attinhcount</structfield></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
<entry><type>int4</type></entry>
<entry></entry>
<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
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.
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
</entry>
</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>
<entry><structfield>attcollation</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.oid</literal></entry>
<entry>
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
The defined collation of the column, or zero if the column is
Spell checking and markup refinement
2011-05-19 00:14:45 +02:00
not of a collatable data type.
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
</entry>
</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>
<entry><structfield>attacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
<entry></entry>
<entry>
Column-level access privileges, if any have been granted specifically
on this column
</entry>
</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>
<entry><structfield>attoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Attribute-level options, as <quote>keyword=value</> strings
</entry>
</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>
<entry><structfield>attfdwoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Attribute-level foreign data wrapper options, as <quote>keyword=value</> strings
</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>
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
<structname>pg_type</> are still valid. This arrangement is needed
to cope with the situation where the dropped column's data type was
later dropped, and so there is no <structname>pg_type</> row anymore.
<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
of <quote>users</> and <quote>groups</>. A user is essentially just a
role with the <structfield>rolcanlogin</> flag set. Any role (with or
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
without <structfield>rolcanlogin</>) 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>
<xref linkend="user-manag"> contains detailed information about user and
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>
<title><structname>pg_authid</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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
<row>
<entry><structfield>rolname</structfield></entry>
<entry><type>name</type></entry>
<entry>Role name</entry>
</row>
<row>
<entry><structfield>rolsuper</structfield></entry>
<entry><type>bool</type></entry>
<entry>Role has superuser privileges</entry>
</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>
<entry><structfield>rolinherit</structfield></entry>
<entry><type>bool</type></entry>
<entry>Role automatically inherits privileges of roles it is a
member of</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
<row>
<entry><structfield>rolcreaterole</structfield></entry>
<entry><type>bool</type></entry>
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
<entry>Role can create more roles</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>
<entry><structfield>rolcreatedb</structfield></entry>
<entry><type>bool</type></entry>
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
<entry>Role can create databases</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>
<entry><structfield>rolcatupdate</structfield></entry>
<entry><type>bool</type></entry>
<entry>
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 update system catalogs directly. (Even a superuser cannot do
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
this unless this column is true)
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
</entry>
</row>
<row>
<entry><structfield>rolcanlogin</structfield></entry>
<entry><type>bool</type></entry>
<entry>
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
Fix omissions in documentation of the pg_roles view. Somehow, column rolconfig got removed from the documentation of the pg_roles view in the 9.0 cycle, although the column is actually still there. In 9.1, we'd also forgotten to document the rolreplication column. Spotted by Sakamoto Masahiko.
2011-07-04 04:12:14 +02:00
session authorization identifier
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
</entry>
</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>
<entry><structfield>rolreplication</structfield></entry>
<entry><type>bool</type></entry>
<entry>
Role is a replication role. That is, this role can initiate streaming
replication (see <xref linkend="streaming-replication">) and set/unset
the system backup mode using <function>pg_start_backup</> and
Fix omissions in documentation of the pg_roles view. Somehow, column rolconfig got removed from the documentation of the pg_roles view in the 9.0 cycle, although the column is actually still there. In 9.1, we'd also forgotten to document the rolreplication column. Spotted by Sakamoto Masahiko.
2011-07-04 04:12:14 +02:00
<function>pg_stop_backup</>
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
</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>
<entry><structfield>rolconnlimit</structfield></entry>
<entry><type>int4</type></entry>
<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
For roles that can log in, this sets maximum number of concurrent
Spell and markup checking
2010-08-17 06:37:21 +02:00
connections this role can make. -1 means no limit.
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
</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
<row>
<entry><structfield>rolpassword</structfield></entry>
<entry><type>text</type></entry>
Elaborate on what gets stored in pg_authid.rolpasswd. Also, add cross-reference from pg_shadow.passwd to pg_authid.rolpasswd and fix a bit of markup I muffed in my previous commit. Per discussion with Josh Kupershmidt.
2010-09-13 19:02:34 +02:00
<entry>
Improve docs for pg_authid encryption description with better markup and a mention of unencrypted passwords.
2011-02-01 04:53:58 +01:00
Password (possibly encrypted); null if none. If the password
is encrypted, this column will begin with the string <literal>md5</>
followed by a 32-character hexadecimal MD5 hash. The MD5 hash
Spell checking and markup refinement
2011-05-19 00:14:45 +02:00
will be of the user's password concatenated to their user name.
Improve docs for pg_authid encryption description with better markup and a mention of unencrypted passwords.
2011-02-01 04:53:58 +01:00
For example, if user <literal>joe</> has password <literal>xyzzy</>,
<productname>PostgreSQL</> will store the md5 hash of
<literal>xyzzyjoe</>. A password that does not follow that
format is assumed to be unencrypted.
Elaborate on what gets stored in pg_authid.rolpasswd. Also, add cross-reference from pg_shadow.passwd to pg_authid.rolpasswd and fix a bit of markup I muffed in my previous commit. Per discussion with Josh Kupershmidt.
2010-09-13 19:02:34 +02:00
</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>
<entry><structfield>rolvaliduntil</structfield></entry>
<entry><type>timestamptz</type></entry>
<entry>Password expiry time (only used for password authentication);
Spell and markup checking
2010-08-17 06:37:21 +02:00
null if no expiration</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>
</tbody>
</tgroup>
</table>
</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>
<title><structname>pg_auth_members</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>roleid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>ID of a role that has a member</entry>
</row>
<row>
<entry><structfield>member</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>ID of a role that is a member of <structfield>roleid</></entry>
</row>
<row>
<entry><structfield>grantor</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>ID of the role that granted this membership</entry>
</row>
<row>
<entry><structfield>admin_option</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>True if <structfield>member</> can grant membership in
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
<structfield>roleid</> to others</entry>
</row>
</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
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
<quote>automatic I/O conversion casts</>, those performed using a data
type's own I/O functions to convert to or from <type>text</> or other
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>
markup correct from Gevik Babakhani
2008-01-29 14:03:50 +01:00
<title><structname>pg_cast</> Columns</title>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>castsource</structfield></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry>OID of the source data type</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>casttarget</structfield></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry>OID of the target data type</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>castfunc</structfield></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry>
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.
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>castcontext</structfield></entry>
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
<entry><type>char</type></entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
<entry></entry>
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
<entry>
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.
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
<literal>e</> means only as an explicit cast (using
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
<literal>CAST</> or <literal>::</> syntax).
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
<literal>a</> means implicitly in assignment
to a target column, as well as explicitly.
<literal>i</> means implicitly in expressions, as well as the
Spell and markup checking
2010-08-17 06:37:21 +02:00
other cases.
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
</entry>
Add unique index on pg_cast.oid, and document pg_cast table.
2002-07-22 22:23:19 +02:00
</row>
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
<row>
<entry><structfield>castmethod</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
Indicates how the cast is performed.
<literal>f</> means that the function specified in the <structfield>castfunc</> field is used.
<literal>i</> means that the input/output functions are used.
Spell and markup checking
2010-08-17 06:37:21 +02:00
<literal>b</> means that the types are binary-coercible, thus no conversion is required.
Add support for user-defined I/O conversion casts.
2008-10-31 09:39:22 +01:00
</entry>
</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,
if present, must be type <type>integer</>; 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,
if present, must be type <type>boolean</>; it receives <literal>true</>
if the cast is an explicit cast, <literal>false</> otherwise.
</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
<quote>length coercion functions</> 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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_class</structname> catalogs tables and most
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
everything else that has columns or is otherwise similar to a
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
table. This includes indexes (but see also
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
<structname>pg_index</structname>), sequences, views, materialized
views, composite types, and TOAST tables; see <structfield>relkind</>.
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
Below, when we mean all of these
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
kinds of objects we speak of <quote>relations</quote>. Not all
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
columns are meaningful for all relation types.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
<table>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_class</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>relname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the table, index, view, etc.</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relnamespace</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></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
<entry>
The OID of the namespace that contains this relation
</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><structfield>reltype</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>
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,
Some preliminary documentation for composite-type stuff.
2004-06-07 06:04:47 +02:00
if any (zero for indexes, which have no <structname>pg_type</> entry)
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
Add missing description of reloftype field
2010-08-25 20:18:41 +02:00
<row>
<entry><structfield>reloftype</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>
For typed tables, the OID of the underlying composite type,
zero for all other relations
</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><structfield>relowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Owner of the relation</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relam</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
Spell checking and markup additions
2002-03-22 20:20:45 +01:00
<entry>If this is an index, the access method used (B-tree, hash, etc.)</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><structfield>relfilenode</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
<entry></entry>
Create a "relation mapping" infrastructure to support changing the relfilenodes of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
2010-02-07 21:48:13 +01:00
<entry>Name of the on-disk file of this relation; zero means this
is a <quote>mapped</> relation whose disk file name is determined
by low-level state</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>
<entry><structfield>reltablespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.oid</literal></entry>
<entry>
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.)
</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><structfield>relpages</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int4</type></entry>
<entry></entry>
<entry>
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
planner. It is updated by <command>VACUUM</command>,
<command>ANALYZE</command>, and a few DDL commands such as
Spell and markup checking
2010-08-17 06:37:21 +02:00
<command>CREATE INDEX</command>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>reltuples</structfield></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
<entry><type>float4</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></entry>
<entry>
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
Number of rows in the table. This is only an estimate used by the
planner. It is updated by <command>VACUUM</command>,
<command>ANALYZE</command>, and a few DDL commands such as
Spell and markup checking
2010-08-17 06:37:21 +02:00
<command>CREATE INDEX</command>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
<entry><structfield>relallvisible</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<entry>
Number of pages that are marked all-visible in the table's
visibility map. This is only an estimate used by the
planner. It is updated by <command>VACUUM</command>,
<command>ANALYZE</command>, and a few DDL commands such as
<command>CREATE INDEX</command>.
</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><structfield>reltoastrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>
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
OID of the TOAST table associated with this table, 0 if none. The
TOAST table stores large attributes <quote>out of line</quote> in a
Spell and markup checking
2010-08-17 06:37:21 +02:00
secondary table.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relhasindex</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
Improvement to CREATE TRIGGER and catalog documentation. Neil Conway
2002-12-17 18:41:30 +01:00
<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
True if this is a table and it has (or recently had) any indexes
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
</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><structfield>relisshared</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>
True if this table is shared across all databases in the cluster. Only
certain system catalogs (such as <structname>pg_database</structname>)
Spell and markup checking
2010-08-17 06:37:21 +02:00
are shared.
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
</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>
Document replacement of pg_class.relistemp with relpersistence. Noted by Tom Lane.
2010-12-13 19:07:08 +01:00
<entry><structfield>relpersistence</structfield></entry>
Show correct datatype for pg_class.relpersistence, plus a typo fix. Thom Brown
2011-01-19 22:09:08 +01:00
<entry><type>char</type></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
<entry></entry>
<entry>
Support unlogged tables. The contents of an unlogged table are WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported.
2010-12-29 12:48:53 +01:00
<literal>p</> = permanent table, <literal>u</> = unlogged table,
<literal>t</> = temporary table
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
</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><structfield>relkind</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>r</> = ordinary table, <literal>i</> = index,
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
<literal>S</> = sequence, <literal>v</> = view,
<literal>m</> = materialized view,
<literal>c</> = composite type, <literal>t</> = TOAST table,
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
<literal>f</> = foreign table
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relnatts</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
<entry></entry>
<entry>
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
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<structname>pg_attribute</structname>. See also
Spell and markup checking
2010-08-17 06:37:21 +02:00
<literal>pg_attribute.attnum</literal>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relchecks</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
<entry></entry>
<entry>
Uppercase CHECK mention in relchecks documentation mention.
2009-02-07 20:27:25 +01:00
Number of <literal>CHECK</> 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
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relhasoids</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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
True if we generate an OID for each row of the relation
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
</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><structfield>relhaspkey</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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
True if the table has (or once had) a primary key
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>relhasrules</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
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
<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
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
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>
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>
<entry><structfield>relhastriggers</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
True if table has (or once had) triggers; see
<link linkend="catalog-pg-trigger"><structname>pg_trigger</structname></link> catalog
</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><structfield>relhassubclass</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>True if table has (or once had) any inheritance children</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01: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>
<entry><structfield>relispopulated</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>True if relation is populated (this is true for all
relations other than some materialized views)</entry>
</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>
<entry><structfield>relreplident</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
Columns used to form <quote>replica identity</> for rows:
<literal>d</> = default (primary key, if any),
<literal>n</> = nothing,
<literal>f</> = all columns
<literal>i</> = index with indisreplident set, or default
</entry>
</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>
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
<entry><structfield>relfrozenxid</structfield></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
<entry><type>xid</type></entry>
<entry></entry>
<entry>
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
(<quote>frozen</>) transaction ID in this table. This is used to track
whether the table needs to be vacuumed in order to prevent transaction
ID wraparound or to allow <literal>pg_clog</> 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.
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
</entry>
</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>
<entry><structfield>relminmxid</structfield></entry>
<entry><type>xid</type></entry>
<entry></entry>
<entry>
All multitransaction IDs before this one have been replaced by a
transaction ID in this table. This is used to track
whether the table needs to be vacuumed in order to prevent multitransaction ID
ID wraparound or to allow <literal>pg_clog</> to be shrunk. Zero
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.
</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><structfield>relacl</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>aclitem[]</type></entry>
<entry></entry>
<entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
<entry><structfield>reloptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Access-method-specific options, as <quote>keyword=value</> strings
</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>
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>
Spell and markup checking
2010-08-17 06:37:21 +02:00
Several of the Boolean flags in <structname>pg_class</> 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
true. For example, <structfield>relhasindex</> is set by
<command>CREATE INDEX</command>, but it is never cleared by
<command>DROP INDEX</command>. Instead, <command>VACUUM</command> clears
<structfield>relhasindex</> if it finds the table has no indexes. This
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
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 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.
See <xref linkend="event-triggers"> for more information.
</para>
<table>
<title><structname>pg_event_trigger</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>evtname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Trigger name (must be unique)</entry>
</row>
<row>
<entry><structfield>evtevent</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Identifies the event for which this trigger fires</entry>
</row>
<row>
<entry><structfield>evtowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the event trigger</entry>
</row>
<row>
<entry><structfield>evtfoid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>The function to be called</entry>
</row>
<row>
<entry><structfield>evtenabled</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
Controls in which <xref linkend="guc-session-replication-role"> modes
the event trigger fires.
<literal>O</> = trigger fires in <quote>origin</> and <quote>local</> modes,
<literal>D</> = trigger is disabled,
<literal>R</> = trigger fires in <quote>replica</> mode,
<literal>A</> = trigger fires always.
</entry>
</row>
<row>
<entry><structfield>evttags</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
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.
</entry>
</row>
</tbody>
</tgroup>
</table>
</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>
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 catalog <structname>pg_constraint</structname> stores check, primary
key, unique, foreign key, and exclusion constraints on tables.
(Column constraints are not treated specially. Every column constraint is
equivalent to some table constraint.)
Not-null constraints are represented in the <structname>pg_attribute</>
catalog, not here.
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>
User-defined constraint triggers (created with <command>CREATE CONSTRAINT
TRIGGER</>) also give rise to an entry in this table.
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_constraint</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>conname</structfield></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><type>name</type></entry>
<entry></entry>
<entry>Constraint name (not necessarily unique!)</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>connamespace</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></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>
The OID of the namespace that contains this constraint
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>contype</structfield></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><type>char</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>c</> = check constraint,
<literal>f</> = foreign key constraint,
<literal>p</> = primary key constraint,
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
<literal>u</> = unique constraint,
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
<literal>t</> = constraint trigger,
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
<literal>x</> = exclusion 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
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>condeferrable</structfield></entry>
<entry><type>bool</type></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></entry>
<entry>Is the constraint deferrable?</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>condeferred</structfield></entry>
<entry><type>bool</type></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></entry>
<entry>Is the constraint deferred by default?</entry>
</row>
Additional required docs for pg_constraint catalog entry Noted by Bernd Helmle
2011-02-15 01:59:29 +01:00
<row>
<entry><structfield>convalidated</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
Rework parsing of ConstraintAttributeSpec to improve NOT VALID handling. The initial commit of the ALTER TABLE ADD FOREIGN KEY NOT VALID feature failed to support labeling such constraints as deferrable. The best fix for this seems to be to fold NOT VALID into ConstraintAttributeSpec. That's a bit more general than the documented syntax, but it allows better-targeted syntax error messages. In addition, do some mostly-but-not-entirely-cosmetic code review for the whole NOT VALID patch.
2011-06-16 01:05:11 +02:00
<entry>Has the constraint been validated?
Enable CHECK constraints to be declared NOT VALID This means that they can initially be added to a large existing table without checking its initial contents, but new tuples must comply to them; a separate pass invoked by ALTER TABLE / VALIDATE can verify existing data and ensure it complies with the constraint, at which point it is marked validated and becomes a normal part of the table ecosystem. An non-validated CHECK constraint is ignored in the planner for constraint_exclusion purposes; when validated, cached plans are recomputed so that partitioning starts working right away. This patch also enables domains to have unvalidated CHECK constraints attached to them as well by way of ALTER DOMAIN / ADD CONSTRAINT / NOT VALID, which can later be validated with ALTER DOMAIN / VALIDATE CONSTRAINT. Thanks to Thom Brown, Dean Rasheed and Jaime Casanova for the various reviews, and Robert Hass for documentation wording improvement suggestions. This patch was sponsored by Enova Financial.
2011-06-02 00:43:50 +02:00
Currently, can only be false for foreign keys and CHECK constraints</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>conrelid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></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>The table this constraint is on; 0 if not a table constraint</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>contypid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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>The domain this constraint is on; 0 if not a domain constraint</entry>
</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>
<entry><structfield>conindid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The index supporting this constraint, if it's a unique, primary
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
key, foreign key, or exclusion constraint; else 0</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>
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><structfield>confrelid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></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>If a foreign key, the referenced table; else 0</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>confupdtype</structfield></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><type>char</type></entry>
<entry></entry>
Document values for pg_constraint confupdtype, confdeltype and confmatchtype columns.
2009-01-09 02:53:10 +01:00
<entry>Foreign key update action code:
Remove tabs from SGML docs.
2009-01-09 16:02:22 +01:00
<literal>a</> = no action,
<literal>r</> = restrict,
<literal>c</> = cascade,
<literal>n</> = set null,
<literal>d</> = set default
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>confdeltype</structfield></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><type>char</type></entry>
<entry></entry>
Document values for pg_constraint confupdtype, confdeltype and confmatchtype columns.
2009-01-09 02:53:10 +01:00
<entry>Foreign key deletion action code:
Remove tabs from SGML docs.
2009-01-09 16:02:22 +01:00
<literal>a</> = no action,
<literal>r</> = restrict,
<literal>c</> = cascade,
<literal>n</> = set null,
<literal>d</> = set default
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>confmatchtype</structfield></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><type>char</type></entry>
<entry></entry>
Document values for pg_constraint confupdtype, confdeltype and confmatchtype columns.
2009-01-09 02:53:10 +01:00
<entry>Foreign key match type:
Remove tabs from SGML docs.
2009-01-09 16:02:22 +01:00
<literal>f</> = full,
<literal>p</> = partial,
Refer to the default foreign key match style as MATCH SIMPLE internally. Previously we followed the SQL92 wording, "MATCH <unspecified>", but since SQL99 there's been a less awkward way to refer to the default style. In addition to the code changes, pg_constraint.confmatchtype now stores this match style as 's' (SIMPLE) rather than 'u' (UNSPECIFIED). This doesn't affect pg_dump or psql because they use pg_get_constraintdef() to reconstruct foreign key definitions. But other client-side code might examine that column directly, so this change will have to be marked as an incompatibility in the 9.3 release notes.
2012-06-18 02:16:07 +02:00
<literal>s</> = simple
Remove tabs from SGML docs.
2009-01-09 16:02:22 +01:00
</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>
<entry><structfield>conislocal</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<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
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.
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
</entry>
</row>
<row>
<entry><structfield>coninhcount</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<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
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.
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
</entry>
</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>
Fix catalog docs to reflect connoinherit change in 09ff76f. Backpatch to 9.2.
2012-09-12 20:23:50 +02:00
<entry><structfield>connoinherit</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
<entry>
This constraint is defined locally for the relation. It is a
non-inheritable constraint.
</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><structfield>conkey</structfield></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry><type>int2[]</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</></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
<entry>If a table constraint (including foreign keys, but not constraint
triggers), list of the constrained columns</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>confkey</structfield></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry><type>int2[]</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</></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>If a foreign key, list of the referenced columns</entry>
</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>
<entry><structfield>conpfeqop</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</></entry>
<entry>If a foreign key, list of the equality operators for PK = FK comparisons</entry>
</row>
<row>
<entry><structfield>conppeqop</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</></entry>
<entry>If a foreign key, list of the equality operators for PK = PK comparisons</entry>
</row>
<row>
<entry><structfield>conffeqop</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</></entry>
<entry>If a foreign key, list of the equality operators for FK = FK comparisons</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>
<entry><structfield>conexclop</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</></entry>
<entry>If an exclusion constraint, list of the per-column exclusion operators</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><structfield>conbin</structfield></entry>
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
<entry><type>pg_node_tree</type></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></entry>
<entry>If a check constraint, an internal representation of the expression</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>consrc</structfield></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><type>text</type></entry>
<entry></entry>
<entry>If a check constraint, a human-readable representation of the expression</entry>
</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
same contents as <structname>pg_index</>.<structfield>indkey</> for the
index.)
</para>
Add note deprecating use of consrc.
2003-10-17 02:55:17 +02:00
<note>
<para>
<structfield>consrc</structfield> is not updated when referenced objects
change; for example, it won't track renaming of columns. Rather than
relying on this field, it's best to use <function>pg_get_constraintdef()</>
to extract the definition of a check constraint.
</para>
</note>
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
<sect1 id="catalog-pg-collation">
<title><structname>pg_collation</structname></title>
<indexterm zone="catalog-pg-collation">
<primary>pg_collation</primary>
</indexterm>
<para>
The catalog <structname>pg_collation</structname> describes the
available collations, which are essentially mappings from an SQL
name to operating system locale categories.
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
See <xref linkend="collation"> for more information.
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>
<table>
<title><structname>pg_collation</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
<entry><structfield>collname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Collation name (unique per namespace and encoding)</entry>
</row>
<row>
<entry><structfield>collnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>
The OID of the namespace that contains this collation
</entry>
</row>
DDL support for collations - collowner field - CREATE COLLATION - ALTER COLLATION - DROP COLLATION - COMMENT ON COLLATION - integration with extensions - pg_dump support for the above - dependency management - psql tab completion - psql \dO command
2011-02-12 14:54:13 +01:00
<row>
<entry><structfield>collowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the collation</entry>
</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>
<entry><structfield>collencoding</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
Create an explicit concept of collations that work for any encoding. Use collencoding = -1 to represent such a collation in pg_collation. We need this to make the "default" entry work sanely, and a later patch will fix the C/POSIX entries to be represented this way instead of duplicating them across all encodings. All lookup operations now search first for an entry that's database-encoding-specific, and then for the same name with collencoding = -1. Also some incidental code cleanup in collationcmds.c and pg_collation.c.
2011-03-11 19:20:11 +01:00
<entry>Encoding in which the collation is applicable, or -1 if it
works for any encoding</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>
<row>
<entry><structfield>collcollate</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
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
<entry><symbol>LC_COLLATE</> for this collation object</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>
<row>
<entry><structfield>collctype</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
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
<entry><symbol>LC_CTYPE</> for this collation object</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>
</tbody>
</tgroup>
</table>
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
<para>
Note that the unique key on this catalog is (<structfield>collname</>,
<structfield>collencoding</>, <structfield>collnamespace</>) not just
(<structfield>collname</>, <structfield>collnamespace</>).
<productname>PostgreSQL</productname> generally ignores all
Create an explicit concept of collations that work for any encoding. Use collencoding = -1 to represent such a collation in pg_collation. We need this to make the "default" entry work sanely, and a later patch will fix the C/POSIX entries to be represented this way instead of duplicating them across all encodings. All lookup operations now search first for an entry that's database-encoding-specific, and then for the same name with collencoding = -1. Also some incidental code cleanup in collationcmds.c and pg_collation.c.
2011-03-11 19:20:11 +01:00
collations that do not have <structfield>collencoding</> equal to
Make a code-cleanup pass over the collations patch. This patch is almost entirely cosmetic --- mostly cleaning up a lot of neglected comments, and fixing code layout problems in places where the patch made lines too long and then pgindent did weird things with that. I did find a bug-of-omission in equalTupleDescs().
2011-04-22 23:43:18 +02:00
either the current database's encoding or -1, and creation of new entries
with the same name as an entry with <structfield>collencoding</> = -1
Create an explicit concept of collations that work for any encoding. Use collencoding = -1 to represent such a collation in pg_collation. We need this to make the "default" entry work sanely, and a later patch will fix the C/POSIX entries to be represented this way instead of duplicating them across all encodings. All lookup operations now search first for an entry that's database-encoding-specific, and then for the same name with collencoding = -1. Also some incidental code cleanup in collationcmds.c and pg_collation.c.
2011-03-11 19:20:11 +01:00
is forbidden. Therefore it is sufficient to use a qualified SQL name
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
(<replaceable>schema</>.<replaceable>name</>) to identify a collation,
even though this is not unique according to the catalog definition.
Create an explicit concept of collations that work for any encoding. Use collencoding = -1 to represent such a collation in pg_collation. We need this to make the "default" entry work sanely, and a later patch will fix the C/POSIX entries to be represented this way instead of duplicating them across all encodings. All lookup operations now search first for an entry that's database-encoding-specific, and then for the same name with collencoding = -1. Also some incidental code cleanup in collationcmds.c and pg_collation.c.
2011-03-11 19:20:11 +01:00
The reason for defining the catalog this way is that
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
<application>initdb</> fills it in at cluster initialization time with
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>
In the <literal>template0</> database, it could be useful to create
collations whose encoding does not match the database encoding,
since they could match the encodings of databases later cloned from
<literal>template0</>. This would currently have to be done manually.
</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
</sect1>
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
encoding conversion procedures. 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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_conversion</> Columns</title>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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><structfield>conname</structfield></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry><type>name</type></entry>
<entry></entry>
<entry>Conversion name (unique within a namespace)</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>connamespace</structfield></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry>
The OID of the namespace that contains this conversion
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>conowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Owner of the conversion</entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>conforencoding</structfield></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry><type>int4</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Source encoding ID</entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>contoencoding</structfield></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry><type>int4</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Destination encoding ID</entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>conproc</structfield></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry>Conversion procedure</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>condefault</structfield></entry>
<entry><type>bool</type></entry>
Add pg_conversion system catalog. Update description for multibyte support.
2002-07-24 07:51:56 +02:00
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>True if this is the default conversion</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
the available databases. Databases are created with the <xref
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
linkend="sql-createdatabase"> command.
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
Consult <xref linkend="managing-databases"> for details about the meaning
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_database</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>datname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
<entry>Database name</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>datdba</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry>Owner of the database, usually the user who created it</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><structfield>encoding</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int4</type></entry>
<entry></entry>
Mention pg_encoding_to_char in entry for pg_database.encoding. Per Larry Rosenman.
2006-06-03 04:53:04 +02:00
<entry>Character encoding for this database
(<function>pg_encoding_to_char()</function> can translate
this number to the encoding name)</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
Make LC_COLLATE and LC_CTYPE database-level settings. Collation and ctype are now more like encoding, stored in new datcollate and datctype columns in pg_database. This is a stripped-down version of Radek Strnad's patch, with further changes by me.
2008-09-23 11:20:39 +02:00
<row>
<entry><structfield>datcollate</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>LC_COLLATE for this database</entry>
</row>
<row>
<entry><structfield>datctype</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>LC_CTYPE for this database</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><structfield>datistemplate</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
If true then this database can be used in the
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>TEMPLATE</literal> clause of <command>CREATE
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
DATABASE</command> to create a new database as a clone of
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
this one
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>datallowconn</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
If false then no one can connect to this database. This is
Spell and markup checking
2010-08-17 06:37:21 +02:00
used to protect the <literal>template0</> database from being altered.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</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>
<entry><structfield>datconnlimit</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<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
Sets maximum number of concurrent connections that can be made
Spell and markup checking
2010-08-17 06:37:21 +02:00
to this database. -1 means no limit.
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
</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><structfield>datlastsysoid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
<entry></entry>
<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
Last system OID in the database; useful
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
particularly to <application>pg_dump</application>
</entry>
</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>
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
<entry><structfield>datfrozenxid</structfield></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
<entry><type>xid</type></entry>
<entry></entry>
<entry>
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
(<quote>frozen</>) transaction ID in this database. This is used to
track whether the database needs to be vacuumed in order to prevent
transaction ID wraparound or to allow <literal>pg_clog</> to be shrunk.
It is the minimum of the per-table
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structname>pg_class</>.<structfield>relfrozenxid</> values.
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
</entry>
</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>
<entry><structfield>datminmxid</structfield></entry>
<entry><type>xid</type></entry>
<entry></entry>
<entry>
All multitransaction IDs before this one have been replaced with a
transaction ID in this database. This is used to
track whether the database needs to be vacuumed in order to prevent
transaction ID wraparound or to allow <literal>pg_clog</> to be shrunk.
It is the minimum of the per-table
<structname>pg_class</>.<structfield>relminmxid</> values.
</entry>
</row>
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
<entry><structfield>dattablespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<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
The default tablespace for the database.
Within this database, all tables for which
<structname>pg_class</>.<structfield>reltablespace</> is zero
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>datacl</structfield></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
<entry><type>aclitem[]</type></entry>
<entry></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
</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>
<title><structname>pg_db_role_setting</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>setdatabase</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-database"><structname>pg_database</structname></link>.oid</literal></entry>
<entry>The OID of the database the setting is applicable to, or zero if not database-specific</entry>
</row>
<row>
<entry><structfield>setrole</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>The OID of the role the setting is applicable to, or zero if not role-specific</entry>
</row>
<row>
<entry><structfield>setconfig</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>Defaults for run-time configuration variables</entry>
</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>
The catalog <structname>pg_default_acl</> stores initial
privileges to be assigned to newly created objects.
</para>
<table>
<title><structname>pg_default_acl</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>defaclrole</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>The OID of the role associated with this entry</entry>
</row>
<row>
<entry><structfield>defaclnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>The OID of the namespace associated with this entry,
or 0 if none</entry>
</row>
<row>
<entry><structfield>defaclobjtype</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
Type of object this entry is for:
<literal>r</> = relation (table, view),
<literal>S</> = sequence,
Fix assorted bugs in privileges-for-types patch. Commit 729205571e81b4767efc42ad7beb53663e08d1ff added privileges on data types, but there were a number of oversights. The implementation of default privileges for types missed a few places, and pg_dump was utterly innocent of the whole concept. Per bug #7741 from Nathan Alden, and subsequent wider investigation.
2012-12-09 06:08:23 +01:00
<literal>f</> = function,
<literal>T</> = type
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
</entry>
</row>
<row>
<entry><structfield>defaclacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
<entry></entry>
<entry>
Access privileges that this type of object should have on creation
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
A <structname>pg_default_acl</> entry shows the initial privileges to
be assigned to an object belonging to the indicated user. There are
currently two types of entry: <quote>global</> entries with
<structfield>defaclnamespace</> = 0, and <quote>per-schema</> entries
that reference a particular schema. If a global entry is present then
it <emphasis>overrides</> the normal hard-wired default privileges
for the object type. A per-schema entry, if present, represents privileges
to be <emphasis>added to</> the global or hard-wired default privileges.
</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,
<emphasis>not</> whatever might be in <structname>pg_default_acl</>
at the moment. <structname>pg_default_acl</> is only consulted during
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
<command>DROP</> commands to find which other objects must be dropped
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
by <command>DROP CASCADE</> or prevent dropping in the <command>DROP
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
RESTRICT</> case.
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_depend</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>classid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The OID of the system catalog the dependent object is in</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>objid</structfield></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><type>oid</type></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>any OID column</entry>
<entry>The OID of the specific dependent object</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>objsubid</structfield></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry><type>int4</type></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></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
For a table column, this is the column number (the
<structfield>objid</> and <structfield>classid</> refer to the
table itself). For all other object types, this column is
Spell and markup checking
2010-08-17 06:37:21 +02:00
zero.
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>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>refclassid</structfield></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><type>oid</type></entry>
Update obsolete examples of error messages; various other minor editing.
2003-09-13 00:17:24 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The OID of the system catalog the referenced object is in</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>refobjid</structfield></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><type>oid</type></entry>
Spell checking, consistent terminology.
2003-11-01 02:56:29 +01:00
<entry>any OID column</entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The OID of the specific referenced object</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>refobjsubid</structfield></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry><type>int4</type></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></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
For a table column, this is the column number (the
<structfield>refobjid</> and <structfield>refclassid</> refer
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.
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>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>deptype</structfield></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><type>char</type></entry>
<entry></entry>
<entry>
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
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>
</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
<structfield>deptype</>:
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<variablelist>
<varlistentry>
<term><symbol>DEPENDENCY_NORMAL</> (<literal>n</>)</term>
<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
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
by specifying <literal>CASCADE</>, in which case the dependent
object is dropped, too. Example: a table column has a normal
dependency on its data type.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>DEPENDENCY_AUTO</> (<literal>a</>)</term>
<listitem>
<para>
The dependent object can be dropped separately from the
referenced object, and should be automatically dropped
(regardless of <literal>RESTRICT</> or <literal>CASCADE</>
mode) if the referenced object is dropped. Example: a named
constraint on a table is made autodependent on the table, so
that it will go away if the table is dropped.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>DEPENDENCY_INTERNAL</> (<literal>i</>)</term>
<listitem>
<para>
The dependent object was created as part of creation of the
referenced object, and is really just a part of its internal
implementation. A <command>DROP</> of the dependent object
will be disallowed outright (we'll tell the user to issue a
<command>DROP</> against the referenced object, instead). A
<command>DROP</> of the referenced object will be propagated
through to drop the dependent object whether
<command>CASCADE</> is specified or not. Example: a trigger
that's created to enforce a foreign-key constraint is made
internally dependent on the constraint's
<structname>pg_constraint</> entry.
</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>
<term><symbol>DEPENDENCY_EXTENSION</> (<literal>e</>)</term>
<listitem>
<para>
The dependent object is a member of the <firstterm>extension</> that is
the referenced object (see
<link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>).
The dependent object can be dropped only via
<command>DROP EXTENSION</> on the referenced object. Functionally
this dependency type acts the same as an internal dependency, but
it's kept separate for clarity and to simplify <application>pg_dump</>.
</para>
</listitem>
</varlistentry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<varlistentry>
<term><symbol>DEPENDENCY_PIN</> (<literal>p</>)</term>
<listitem>
<para>
There is no dependent object; this type of entry is a signal
that the system itself depends on the referenced object, and so
that object must never be deleted. Entries of this type are
created only by <command>initdb</command>. The columns for the
dependent object contain zeroes.
</para>
</listitem>
</varlistentry>
</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>
</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>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
The catalog <structname>pg_description</> stores optional descriptions
(comments) for each database object. Descriptions can be manipulated
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
with the <xref linkend="sql-comment"> 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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_description</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>objoid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>any OID column</entry>
<entry>The OID of the object this description pertains to</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>classoid</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The OID of the system catalog this object appears in</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>objsubid</structfield></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
<entry><type>int4</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
For a comment on a table column, this is the column number (the
<structfield>objoid</> and <structfield>classoid</> refer to
the table itself). For all other object types, this column is
Spell and markup checking
2010-08-17 06:37:21 +02:00
zero.
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
</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><structfield>description</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>text</type></entry>
<entry></entry>
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
<entry>Arbitrary text that serves as the description of this object</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>
<title><structname>pg_enum</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>enumtypid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>The OID of the <structname>pg_type</> entry owning this enum value</entry>
</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>
<entry><structfield>enumsortorder</structfield></entry>
<entry><type>float4</type></entry>
<entry></entry>
<entry>The sort position of this enum value within its enum type</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><structfield>enumlabel</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>The textual label for this enum value</entry>
</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
positions 1..<replaceable>n</>. But members added later might be given
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
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
about the installed extensions. See <xref linkend="extend-extensions">
for details about extensions.
</para>
<table>
<title><structname>pg_extension</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>extname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the extension</entry>
</row>
<row>
<entry><structfield>extowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the extension</entry>
</row>
<row>
<entry><structfield>extnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>Schema containing the extension's exported objects</entry>
</row>
<row>
<entry><structfield>extrelocatable</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>True if extension can be relocated to another schema</entry>
</row>
<row>
<entry><structfield>extversion</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
Add support for multiple versions of an extension and ALTER EXTENSION UPDATE. This follows recent discussions, so it's quite a bit different from Dimitri's original. There will probably be more changes once we get a bit of experience with it, but let's get it in and start playing with it. This is still just core code. I'll start converting contrib modules shortly. Dimitri Fontaine and Tom Lane
2011-02-12 03:25:20 +01:00
<entry>Version name for the extension</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>
<entry><structfield>extconfig</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>Array of <type>regclass</> OIDs for the extension's configuration
table(s), or <literal>NULL</> if none</entry>
</row>
<row>
<entry><structfield>extcondition</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>Array of <literal>WHERE</>-clause filter conditions for the
extension's configuration table(s), or <literal>NULL</> if none</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
Note that unlike most catalogs with a <quote>namespace</> column,
<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>
<title><structname>pg_foreign_data_wrapper</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>fdwname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the foreign-data wrapper</entry>
</row>
<row>
<entry><structfield>fdwowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the foreign-data wrapper</entry>
</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>
<entry><structfield>fdwhandler</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>
References a handler function that is responsible for
supplying execution routines for the foreign-data wrapper.
Zero if no handler is provided
</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>
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
<entry><structfield>fdwvalidator</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>
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
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
</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>
<entry><structfield>fdwacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
<entry></entry>
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
</entry>
</row>
<row>
<entry><structfield>fdwoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Foreign-data wrapper specific options, as <quote>keyword=value</> strings
</entry>
</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>
<title><structname>pg_foreign_server</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>srvname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the foreign server</entry>
</row>
<row>
<entry><structfield>srvowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the foreign server</entry>
</row>
<row>
<entry><structfield>srvfdw</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-foreign-data-wrapper"><structname>pg_foreign_data_wrapper</structname></link>.oid</literal></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
<entry>OID of the foreign-data wrapper of this foreign server</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>
<entry><structfield>srvtype</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>Type of the server (optional)</entry>
</row>
<row>
<entry><structfield>srvversion</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>Version of the server (optional)</entry>
</row>
<row>
<entry><structfield>srvacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
<entry></entry>
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
</entry>
</row>
<row>
<entry><structfield>srvoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
Foreign server specific options, as <quote>keyword=value</> strings
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
</entry>
</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
primarily represented by a <structname>pg_class</structname> entry,
just like a regular table. Its <structname>pg_foreign_table</structname>
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>
<title><structname>pg_foreign_table</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>ftrelid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></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
<entry>OID of the <structname>pg_class</> entry for this foreign table</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>
<entry><structfield>ftserver</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.oid</literal></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
<entry>OID of the foreign server for this foreign table</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>
<entry><structfield>ftoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<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
Foreign table options, as <quote>keyword=value</> strings
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
</entry>
</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
<structname>pg_class</structname>.
</para>
<table>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_index</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>indexrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The OID of the <structname>pg_class</> entry for this index</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><structfield>indrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The OID of the <structname>pg_class</> entry for the table this index is for</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
<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
<entry><structfield>indnatts</structfield></entry>
<entry><type>int2</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></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
<entry>The number of columns in the index (duplicates
<literal>pg_class.relnatts</literal>)</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><structfield>indisunique</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>If true, this is a unique index</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><structfield>indisprimary</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></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
<entry>If true, this index represents the primary key of the table
(<structfield>indisunique</> should always be true when this is true)</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>
<entry><structfield>indisexclusion</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>If true, this index supports an exclusion constraint</entry>
</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>
<entry><structfield>indimmediate</structfield></entry>
<entry><type>bool</type></entry>
<entry></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
<entry>If true, the uniqueness check is enforced immediately on
insertion
(irrelevant if <structfield>indisunique</> is not true)</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>
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
<entry><structfield>indisclustered</structfield></entry>
<entry><type>bool</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></entry>
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
<entry>If true, the table was last clustered on this index</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>
<entry><structfield>indisvalid</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>
If true, the index is currently valid for queries. False means the
index is possibly incomplete: it must still be modified by
<command>INSERT</>/<command>UPDATE</> operations, but it cannot safely
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.
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
</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>
<entry><structfield>indcheckxmin</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
If true, queries must not use the index until the <structfield>xmin</>
Spell and markup checking
2010-08-17 06:37:21 +02:00
of this <structname>pg_index</> row is below their <symbol>TransactionXmin</symbol>
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
event horizon, because the table may contain broken HOT chains with
incompatible rows that they can see
</entry>
</row>
<row>
<entry><structfield>indisready</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
If true, the index is currently ready for inserts. False means the
index must be ignored by <command>INSERT</>/<command>UPDATE</>
Spell and markup checking
2010-08-17 06:37:21 +02:00
operations.
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
</entry>
</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>
<entry><structfield>indislive</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
If false, the index is in process of being dropped, and should be
ignored for all purposes (including HOT-safety decisions)
</entry>
</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>
<entry><structfield>indisreplident</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
If true this index has been chosen as <quote>replica identity</>
using <command>ALTER TABLE ... REPLICA IDENTITY USING INDEX
...</>
</entry>
</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>
<entry><structfield>indkey</structfield></entry>
<entry><type>int2vector</type></entry>
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></entry>
<entry>
This is an array of <structfield>indnatts</structfield> values that
indicate which table columns this index indexes. For example a value
of <literal>1 3</literal> would mean that the first and the third table
columns make up the index key. A zero in this array indicates that the
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.
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
</entry>
</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>
<entry><structfield>indcollation</structfield></entry>
<entry><type>oidvector</type></entry>
<entry><literal><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.oid</literal></entry>
<entry>
For each column in the index key, this contains the OID of the
collation to use for the index.
</entry>
</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>
<entry><structfield>indclass</structfield></entry>
<entry><type>oidvector</type></entry>
<entry><literal><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.oid</literal></entry>
<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
For each column in the index key, this contains the OID of
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
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.
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
</entry>
</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>
<entry><structfield>indoption</structfield></entry>
<entry><type>int2vector</type></entry>
<entry></entry>
<entry>
This is an array of <structfield>indnatts</structfield> values that
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.
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
</entry>
</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>
<entry><structfield>indexprs</structfield></entry>
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
<entry><type>pg_node_tree</type></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
<entry></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>
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
entry in <structfield>indkey</>. Null if all index attributes
are simple references.
</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><structfield>indpred</structfield></entry>
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
<entry><type>pg_node_tree</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>
Expression tree (in <function>nodeToString()</function>
representation) for partial index predicate. Null if not a
partial index.
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_inherits</> records information about
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
table inheritance hierarchies. There is one entry for each direct
child table 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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_inherits</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>inhrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>
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
The OID of the child table
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>inhparent</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>
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
The OID of the parent table
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>inhseqno</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int4</type></entry>
<entry></entry>
<entry>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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-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.
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
See <xref linkend="sql-createlanguage">
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_language</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>lanname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>Name of the language</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>
<entry><structfield>lanowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the language</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><structfield>lanispl</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>lanpltrusted</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>lanplcallfoid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>
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
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
language
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
<entry><structfield>laninline</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>
This references a function that is responsible for executing
<quote>inline</> anonymous code blocks
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02: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.
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
</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>lanvalidator</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></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
<entry>
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.
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
</entry>
</row>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>lanacl</structfield></entry>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
<entry><type>aclitem[]</type></entry>
<entry></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
</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
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
segments or <quote>pages</> small enough to be conveniently stored as rows
in <structname>pg_largeobject</structname>.
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 amount of data per page is defined to be <symbol>LOBLKSIZE</> (which is currently
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>BLCKSZ/4</>, 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>
Stamp HEAD as 9.0devel, and update various places that were referring to 8.5 (hope I got 'em all). Per discussion, this release will be 9.0 not 8.5.
2010-02-17 05:19:41 +01:00
Prior to <productname>PostgreSQL</> 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
Spell and markup checking
2010-08-17 06:37:21 +02:00
<link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</></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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_largeobject</> Columns</title>
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
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</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>References</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>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>loid</structfield></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><type>oid</type></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><literal><link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</structname></link>.oid</literal></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>Identifier of the large object that includes this page</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>pageno</structfield></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><type>int4</type></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></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>Page number of this page within its large object
(counting from zero)</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>data</structfield></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><type>bytea</type></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></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>
Actual data stored in the large object.
Spell and markup checking
2010-08-17 06:37:21 +02:00
This will never be more than <symbol>LOBLKSIZE</> bytes and might be less.
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>
</row>
</tbody>
</tgroup>
</table>
<para>
Each row of <structname>pg_largeobject</structname> holds data
for one page of a large object, beginning at
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
byte offset (<literal>pageno * LOBLKSIZE</>) 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
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>LOBLKSIZE</> 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
Spell and markup checking
2010-08-17 06:37:21 +02:00
<link linkend="catalog-pg-largeobject"><structname>pg_largeobject</></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>
<title><structname>pg_largeobject_metadata</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
<entry><structfield>lomowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Owner of the large object</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>
<entry><structfield>lomacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
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
<entry></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>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
</entry>
</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
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_namespace</> stores namespaces.
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_namespace</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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><structfield>nspname</structfield></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
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the namespace</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>nspowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Owner of the namespace</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>nspacl</structfield></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
<entry><type>aclitem[]</type></entry>
<entry></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02: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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_opclass</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
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><structfield>opcmethod</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
Spell checking, consistent terminology.
2003-11-01 02:56:29 +01:00
<entry>Index access method operator class is for</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>opcname</structfield></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
<entry><type>name</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Name of this operator class</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>opcnamespace</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Namespace of this operator class</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>opcowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the operator class</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>
<entry><structfield>opcfamily</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.oid</literal></entry>
<entry>Operator family containing the operator class</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>opcintype</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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
<entry>Data type that the operator class indexes</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>opcdefault</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>True if this operator class is the default for <structfield>opcintype</></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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>opckeytype</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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
<entry>Type of data stored in index, or zero if same as <structfield>opcintype</></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>
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
An operator class's <structfield>opcmethod</> must match the
<structname>opfmethod</> of its containing operator family.
Also, there must be no more than one <structname>pg_opclass</structname>
row having <structname>opcdefault</> true for any given combination of
<structname>opcmethod</> and <structname>opcintype</>.
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>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
The catalog <structname>pg_operator</> stores information about operators.
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
See <xref linkend="sql-createoperator">
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_operator</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>oprname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the operator</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprnamespace</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></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
<entry>
The OID of the namespace that contains this operator
</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><structfield>oprowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Owner of the operator</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><structfield>oprkind</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>b</> = infix (<quote>both</quote>), <literal>l</> = prefix
(<quote>left</quote>), <literal>r</> = postfix (<quote>right</quote>)
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</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><structfield>oprcanmerge</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>This operator supports merge joins</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><structfield>oprcanhash</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
Revise hash join and hash aggregation code to use the same datatype- specific hash functions used by hash indexes, rather than the old not-datatype-aware ComputeHashFunc routine. This makes it safe to do hash joining on several datatypes that previously couldn't use hashing. The sets of datatypes that are hash indexable and hash joinable are now exactly the same, whereas before each had some that weren't in the other.
2003-06-23 00:04:55 +02:00
<entry>This operator supports hash joins</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><structfield>oprleft</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Type of the left operand</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprright</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Type of the right operand</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprresult</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Type of the result</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprcom</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Commutator of this operator, if any</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprnegate</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</literal></entry>
Change to Negator.
2000-12-11 19:26:37 +01:00
<entry>Negator of this operator, if any</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><structfield>oprcode</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Function that implements this operator</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprrest</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Restriction selectivity estimation function for this operator</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>oprjoin</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Join selectivity estimation function for this operator</entry>
</row>
</tbody>
</tgroup>
</table>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<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
Unused column contain zeroes. For example, <structfield>oprleft</structfield>
is zero for a prefix operator.
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +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
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
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<quote>compatible</>, 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>
Operator families are described at length in <xref linkend="xindex">.
</para>
<table>
<title><structname>pg_opfamily</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>opfmethod</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
<entry>Index access method operator family is for</entry>
</row>
<row>
<entry><structfield>opfname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of this operator family</entry>
</row>
<row>
<entry><structfield>opfnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>Namespace of this operator family</entry>
</row>
<row>
<entry><structfield>opfowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the operator family</entry>
</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>
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
<sect1 id="catalog-pg-pltemplate">
<title><structname>pg_pltemplate</structname></title>
<indexterm zone="catalog-pg-pltemplate">
<primary>pg_pltemplate</primary>
</indexterm>
<para>
The catalog <structname>pg_pltemplate</structname> stores
<quote>template</> information for procedural languages.
A template for a language allows the language to be created in a
particular database by a simple <command>CREATE LANGUAGE</> command,
with no need to specify implementation details.
</para>
<para>
Unlike most system catalogs, <structname>pg_pltemplate</structname>
is shared across all databases of a cluster: there is only one
copy of <structname>pg_pltemplate</structname> per cluster, not
one per database. This allows the information to be accessible in
each database as it is needed.
</para>
<table>
<title><structname>pg_pltemplate</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>tmplname</structfield></entry>
<entry><type>name</type></entry>
<entry>Name of the language this template is for</entry>
</row>
<row>
<entry><structfield>tmpltrusted</structfield></entry>
<entry><type>boolean</type></entry>
<entry>True if language is considered trusted</entry>
</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>
<entry><structfield>tmpldbacreate</structfield></entry>
<entry><type>boolean</type></entry>
<entry>True if language may be created by a database owner</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>
<entry><structfield>tmplhandler</structfield></entry>
<entry><type>text</type></entry>
<entry>Name of call handler function</entry>
</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>
<entry><structfield>tmplinline</structfield></entry>
<entry><type>text</type></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Name of anonymous-block handler function, or null if none</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>
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>
<entry><structfield>tmplvalidator</structfield></entry>
<entry><type>text</type></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Name of validator function, or null if none</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>
<row>
<entry><structfield>tmpllibrary</structfield></entry>
<entry><type>text</type></entry>
<entry>Path of shared library that implements language</entry>
</row>
<row>
<entry><structfield>tmplacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
Adjust documentation about pg_pltemplate to reflect latest thinking. It's more likely that pg_pltemplate will go away in the future than that we'll add additional specialized infrastructure for it.
2011-03-05 21:34:10 +01:00
<entry>Access privileges for template (not actually used)</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>
</tbody>
</tgroup>
</table>
<para>
There are not currently any commands that manipulate procedural language
templates; to change the built-in information, a superuser must modify
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
the table using ordinary <command>INSERT</command>, <command>DELETE</command>,
Adjust documentation about pg_pltemplate to reflect latest thinking. It's more likely that pg_pltemplate will go away in the future than that we'll add additional specialized infrastructure for it.
2011-03-05 21:34:10 +01:00
or <command>UPDATE</command> commands.
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
</para>
Adjust documentation about pg_pltemplate to reflect latest thinking. It's more likely that pg_pltemplate will go away in the future than that we'll add additional specialized infrastructure for it.
2011-03-05 21:34:10 +01:00
<note>
<para>
It is likely that <structname>pg_pltemplate</> will be removed in some
future release of <productname>PostgreSQL</productname>, in favor of
keeping this knowledge about procedural languages in their respective
extension installation scripts.
</para>
</note>
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
</sect1>
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 better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
The catalog <structname>pg_proc</> stores information about functions (or procedures).
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
See <xref linkend="sql-createfunction">
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
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>
The table contains data for aggregate functions as well as plain functions.
If <structfield>proisagg</structfield> is true, there should be a matching
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
row in <structfield>pg_aggregate</structfield>.
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_proc</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>proname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the function</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>pronamespace</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></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
<entry>
The OID of the namespace that contains this function
</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><structfield>proowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Owner of the function</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><structfield>prolang</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Fix misspellings: langauge -> language.
2004-07-05 01:34:24 +02:00
<entry><literal><link linkend="catalog-pg-language"><structname>pg_language</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>Implementation language or call interface of this function</entry>
</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>
<entry><structfield>procost</structfield></entry>
<entry><type>float4</type></entry>
<entry></entry>
<entry>Estimated execution cost (in units of
<xref linkend="guc-cpu-operator-cost">); if <structfield>proretset</>,
this is cost per row returned</entry>
</row>
<row>
<entry><structfield>prorows</structfield></entry>
<entry><type>float4</type></entry>
<entry></entry>
<entry>Estimated number of result rows (zero if not <structfield>proretset</>)</entry>
</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>
<entry><structfield>provariadic</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>Data type of the variadic array parameter's elements,
or zero if the function does not have a variadic parameter</entry>
</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>
<entry><structfield>protransform</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Code review for protransform patches. Fix loss of previous expression-simplification work when a transform function fires: we must not simply revert to untransformed input tree. Instead build a dummy FuncExpr node to pass to the transform function. This has the additional advantage of providing a simpler, more uniform API for transform functions. Move documentation to a somewhat less buried spot, relocate some poorly-placed code, be more wary of null constants and invalid typmod values, add an opr_sanity check on protransform function signatures, and some other minor cosmetic adjustments. Note: although this patch touches pg_proc.h, no need for catversion bump, because the changes are cosmetic and don't actually change the intended catalog contents.
2012-03-23 22:29:57 +01:00
<entry>Calls to this function can be simplified by this other function
(see <xref linkend="xfunc-transform-functions">)</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>proisagg</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></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
<entry>Function is an aggregate function</entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</row>
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>
<entry><structfield>proiswindow</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Function is a window function</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><structfield>prosecdef</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry>Function is a security definer (i.e., a <quote>setuid</>
function)</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>
<entry><structfield>proleakproof</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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.
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
</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><structfield>proisstrict</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>proretset</structfield></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
<entry><type>bool</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Function returns a set (i.e., multiple values of the specified
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
data type)</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>provolatile</structfield></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
<entry><type>char</type></entry>
<entry></entry>
<entry>
<structfield>provolatile</structfield> tells whether the function's
result depends only on its input arguments, or is affected by outside
factors.
It is <literal>i</literal> for <quote>immutable</> functions,
which always deliver the same result for the same inputs.
It is <literal>s</literal> for <quote>stable</> functions,
whose results (for fixed inputs) do not change within a scan.
It is <literal>v</literal> for <quote>volatile</> 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.)
</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><structfield>pronargs</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
<entry></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
<entry>Number of input arguments</entry>
</row>
<row>
<entry><structfield>pronargdefaults</structfield></entry>
<entry><type>int2</type></entry>
<entry></entry>
<entry>Number of arguments that have defaults</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><structfield>prorettype</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry>Data type of the return value</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><structfield>proargtypes</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oidvector</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></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
<entry>
An array with 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
<literal>VARIADIC</> arguments), and thus represents
Spell and markup checking
2010-08-17 06:37:21 +02:00
the call signature of the function.
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
</entry>
</row>
<row>
<entry><structfield>proallargtypes</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>
An array with 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
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structfield>proargtypes</> is subscripted from 0.
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
</entry>
</row>
<row>
<entry><structfield>proargmodes</structfield></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
<entry><type>char[]</type></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
<entry></entry>
<entry>
An array with the modes of the function arguments, encoded as
Spellchecking and such
2006-10-23 20:10:32 +02:00
<literal>i</literal> for <literal>IN</> arguments,
<literal>o</literal> for <literal>OUT</> arguments,
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
<literal>b</literal> for <literal>INOUT</> arguments,
Implement SQL-spec RETURNS TABLE syntax for functions. (Unlike the original submission, this patch treats TABLE output parameters as being entirely equivalent to OUT parameters -- tgl) Pavel Stehule
2008-07-18 05:32:53 +02:00
<literal>v</literal> for <literal>VARIADIC</> arguments,
<literal>t</literal> for <literal>TABLE</> arguments.
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
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 subscripts correspond to positions of
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structfield>proallargtypes</> not <structfield>proargtypes</>.
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
</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>
<entry><structfield>proargnames</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
An array with the names of the function arguments.
Arguments without a name are set to empty strings in the array.
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
If none of the arguments have a name, this field will be null.
Note that subscripts correspond to positions of
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structfield>proallargtypes</> not <structfield>proargtypes</>.
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
</entry>
</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>
<entry><structfield>proargdefaults</structfield></entry>
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
<entry><type>pg_node_tree</type></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
<entry></entry>
<entry>
Expression trees (in <function>nodeToString()</function> representation)
for default values. This is a list with
<structfield>pronargdefaults</> elements, corresponding to the last
<replaceable>N</> <emphasis>input</> arguments (i.e., the last
<replaceable>N</> <structfield>proargtypes</> 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.
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
</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><structfield>prosrc</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>text</type></entry>
<entry></entry>
<entry>
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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>probin</structfield></entry>
Cause pg_proc.probin to be declared as text, not bytea. Everything was already treating it as text anyway, to the point that I couldn't find anything to change except the datatype markings in catalog/*.h. The only effect that the bytea declaration had was to cause byteaout() to be invoked when pg_dump (or another client program) inspected the column value. Since pg_dump wasn't expecting that, but just treating what it got as text, the net result is that dump and reload would mangle any backslashes or non-ASCII characters in the filename string for a C-language function. That is a very long-standing bug, but given the lack of field complaints it doesn't seem worth trying to find a back-patchable fix. We'll just make this change to fix it going forward. This change will also forestall problems after the planned change to let bytea emit hex output instead of escaped characters.
2009-08-04 06:04:12 +02:00
<entry><type>text</type></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry></entry>
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
<entry>
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.
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>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</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>
<entry><structfield>proconfig</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>Function's local settings for run-time configuration variables</entry>
</row>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>proacl</structfield></entry>
Privileges on functions and procedural languages
2002-02-19 00:11:58 +01:00
<entry><type>aclitem[]</type></entry>
<entry></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
</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
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
name (link symbol). 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
text. <structfield>probin</structfield> is unused except for
dynamically-loaded C functions, for which it gives the name of the
shared library file containing the function.
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
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>
<title><structname>pg_range</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>rngtypid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
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
<entry>OID of the range type</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>
<entry><structfield>rngsubtype</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
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
<entry>OID of the element type (subtype) of this range type</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>
<entry><structfield>rngcollation</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.oid</literal></entry>
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
<entry>OID of the collation used for range comparisons, or 0 if none</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>
<entry><structfield>rngsubopc</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.oid</literal></entry>
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
<entry>OID of the subtype's operator class used for range comparisons</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>
<entry><structfield>rngcanonical</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
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
<entry>OID of the function to convert a range value into canonical form,
or 0 if none</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>
<entry><structfield>rngsubdiff</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
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
<entry>OID of the function to return the difference between two element
values as <type>double precision</type>, or 0 if none</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>
<structfield>rngsubopc</> (plus <structfield>rngcollation</>, if the
element type is collatable) determines the sort ordering used by the range
type. <structfield>rngcanonical</> is used when the element type is
discrete. <structfield>rngsubdiff</> is optional but should be supplied to
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>
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_rewrite</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>rulename</structfield></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><type>name</type></entry>
<entry></entry>
<entry>Rule name</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ev_class</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></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>The table this rule is for</entry>
</row>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ev_type</structfield></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry><type>char</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
Event type that the rule is for: 1 = <command>SELECT</>, 2 =
<command>UPDATE</>, 3 = <command>INSERT</>, 4 =
<command>DELETE</>
</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>
<entry><structfield>ev_enabled</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
Remove tabs in SGML files.
2007-03-22 16:46:56 +01:00
Controls in which <xref linkend="guc-session-replication-role"> modes
the rule fires.
<literal>O</> = rule fires in <quote>origin</> and <quote>local</> modes,
<literal>D</> = rule is disabled,
<literal>R</> = rule fires in <quote>replica</> mode,
<literal>A</> = rule fires always.
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>is_instead</structfield></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><type>bool</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>True if the rule is an <literal>INSTEAD</literal> rule</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ev_qual</structfield></entry>
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
<entry><type>pg_node_tree</type></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></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
Expression tree (in the form of a
<function>nodeToString()</function> representation) for the
rule's qualifying condition
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>ev_action</structfield></entry>
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
<entry><type>pg_node_tree</type></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></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
Query tree (in the form of a
<function>nodeToString()</function> representation) for the
rule's action
</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
with the <xref linkend="sql-security-label"> command. For an easier
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>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>objoid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>The OID of the object this security label pertains to</entry>
</row>
<row>
<entry><structfield>classoid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The OID of the system catalog this object appears in</entry>
</row>
<row>
<entry><structfield>objsubid</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<entry>
For a security label on a table column, this is the column number (the
<structfield>objoid</> and <structfield>classoid</> refer to
the table itself). For all other object types, this column is
zero.
</entry>
</row>
<row>
<entry><structfield>provider</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>The label provider associated with this label.</entry>
</row>
<row>
<entry><structfield>label</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>The security label applied to this object.</entry>
</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
<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>
<title><structname>pg_shdepend</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>dbid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-database"><structname>pg_database</structname></link>.oid</literal></entry>
<entry>The OID of the database the dependent object is in,
or zero for a shared object</entry>
</row>
<row>
<entry><structfield>classid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The OID of the system catalog the dependent object is in</entry>
</row>
<row>
<entry><structfield>objid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>The OID of the specific dependent object</entry>
</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>
<entry><structfield>objsubid</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<entry>
For a table column, this is the column number (the
<structfield>objid</> and <structfield>classid</> 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.
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
</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><structfield>refclassid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The OID of the system catalog the referenced object is in
(must be a shared catalog)</entry>
</row>
<row>
<entry><structfield>refobjid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>The OID of the specific referenced object</entry>
</row>
<row>
<entry><structfield>deptype</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
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
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
</entry>
</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
<structfield>deptype</>:
<variablelist>
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_OWNER</> (<literal>o</>)</term>
<listitem>
<para>
The referenced object (which must be a role) is the owner of the
dependent object.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_ACL</> (<literal>a</>)</term>
<listitem>
<para>
The referenced object (which must be a role) is mentioned in the
ACL (access control list, i.e., privileges list) of the
dependent object. (A <symbol>SHARED_DEPENDENCY_ACL</> entry is
not made for the owner of the object, since the owner will have
a <symbol>SHARED_DEPENDENCY_OWNER</> entry anyway.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><symbol>SHARED_DEPENDENCY_PIN</> (<literal>p</>)</term>
<listitem>
<para>
There is no dependent object; this type of entry is a signal
that the system itself depends on the referenced object, and so
that object must never be deleted. Entries of this type are
created only by <command>initdb</command>. The columns for the
dependent object contain zeroes.
</para>
</listitem>
</varlistentry>
</variablelist>
Update documentation on may/can/might: Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
Other dependency flavors might be needed in future. Note in particular
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
that the current definition only supports roles as referenced objects.
</para>
</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
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
manipulated with the <xref linkend="sql-comment"> 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>
<title><structname>pg_shdescription</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>objoid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>The OID of the object this description pertains to</entry>
</row>
<row>
<entry><structfield>classoid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The OID of the system catalog this object appears in</entry>
</row>
<row>
<entry><structfield>description</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
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
<entry>Arbitrary text that serves as the description of this object</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
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
with the <xref linkend="sql-security-label"> command. For an easier
way to view security labels, see <xref linkend="view-pg-seclabels">.
</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>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>objoid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>The OID of the object this security label pertains to</entry>
</row>
<row>
<entry><structfield>classoid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The OID of the system catalog this object appears in</entry>
</row>
<row>
<entry><structfield>provider</structfield></entry>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
<entry><type>text</type></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
<entry></entry>
<entry>The label provider associated with this label.</entry>
</row>
<row>
<entry><structfield>label</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>The security label applied to this object.</entry>
</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
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
created by <xref linkend="sql-analyze">
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>
Normally there is one entry, with <structfield>stainherit</> =
<literal>false</>, for each table column that has been analyzed.
If the table has inheritance children, a second entry with
<structfield>stainherit</> = <literal>true</> is also created. This row
represents the column's statistics over the inheritance tree, i.e.,
statistics for the data you'd see with
<literal>SELECT <replaceable>column</> FROM <replaceable>table</>*</literal>,
whereas the <structfield>stainherit</> = <literal>false</> row represents
the results of
<literal>SELECT <replaceable>column</> FROM ONLY <replaceable>table</></literal>.
</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
always have <structfield>stainherit</> = <literal>false</>.
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_statistic</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>starelid</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
First steps towards statistics on expressional (nee functional) indexes. This commit teaches ANALYZE to store such stats in pg_statistic, but nothing is done yet about teaching the planner to use 'em. Also, repair longstanding oversight in separate ANALYZE command: it updated the pg_class.relpages and reltuples counts for the table proper, but not for indexes.
2004-02-15 22:01:39 +01:00
<entry>The table or index that the described column belongs to</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>staattnum</structfield></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
<entry><type>int2</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></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
<entry>The number of the described column</entry>
</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>
<entry><structfield>stainherit</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>If true, the stats include inheritance child columns, not just the
values in the specified relation</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>stanullfrac</structfield></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
<entry><type>float4</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The fraction of the column's entries that are null</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>stawidth</structfield></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
<entry><type>int4</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The average stored width, in bytes, of nonnull entries</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>stadistinct</structfield></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
<entry><type>float4</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>The number of distinct nonnull data values in the column.
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
A value greater than zero is the actual number of distinct values.
Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Robert Haas
2009-08-03 00:14:53 +02:00
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 values appear about
twice on the average could be represented by
<structfield>stadistinct</> = -0.5.
Spell and markup checking
2010-08-17 06:37:21 +02:00
A zero value means the number of distinct values is unknown.
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
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>stakind<replaceable>N</></structfield></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
<entry><type>int2</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
A code number indicating the kind of statistics stored in the
<replaceable>N</>th <quote>slot</quote> of the
Spell and markup checking
2010-08-17 06:37:21 +02:00
<structname>pg_statistic</structname> 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
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>staop<replaceable>N</></structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-operator"><structname>pg_operator</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
An operator used to derive the statistics stored in the
<replaceable>N</>th <quote>slot</quote>. For example, a
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.
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
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>stanumbers<replaceable>N</></structfield></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
<entry><type>float4[]</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
Numerical statistics of the appropriate kind for the
Spell and markup checking
2010-08-17 06:37:21 +02:00
<replaceable>N</>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
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
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>stavalues<replaceable>N</></structfield></entry>
Instead of storing pg_statistic stavalues entries as text strings, store them as arrays of the internal datatype. This requires treating the stavalues columns as 'anyarray' rather than 'text[]', which is not 100% kosher but seems to work fine for the purposes we need for pg_statistic. Perhaps in the future 'anyarray' will be allowed more generally.
2003-03-23 06:14:37 +01:00
<entry><type>anyarray</type></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
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
Column data values of the appropriate kind for the
Spell and markup checking
2010-08-17 06:37:21 +02:00
<replaceable>N</>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
these columns' type more specifically than <type>anyarray</>.
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
</entry>
</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
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>
<title><structname>pg_tablespace</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>spcname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Tablespace name</entry>
</row>
<row>
<entry><structfield>spcowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></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
<entry>Owner of the tablespace, usually the user who created it</entry>
</row>
<row>
<entry><structfield>spcacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
<entry></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>
Access privileges; see
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
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
for details
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
</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>
<entry><structfield>spcoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Tablespace-level options, as <quote>keyword=value</> strings
</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
</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.
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02: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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_trigger</> Columns</title>
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
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgrelid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></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>The table this trigger is on</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgname</structfield></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><type>name</type></entry>
<entry></entry>
Update some obsolete comments and column descriptions.
2002-09-24 23:26:44 +02:00
<entry>Trigger name (must be unique among triggers of same table)</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgfoid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></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>The function to be called</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgtype</structfield></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><type>int2</type></entry>
<entry></entry>
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
<entry>Bit mask identifying trigger firing conditions</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgenabled</structfield></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
<entry><type>char</type></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></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
<entry>
Remove tabs in SGML files.
2007-03-22 16:46:56 +01:00
Controls in which <xref linkend="guc-session-replication-role"> modes
the trigger fires.
<literal>O</> = trigger fires in <quote>origin</> and <quote>local</> modes,
<literal>D</> = trigger is disabled,
<literal>R</> = trigger fires in <quote>replica</> mode,
<literal>A</> = trigger fires always.
</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>
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
<entry><structfield>tgisinternal</structfield></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><type>bool</type></entry>
<entry></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
<entry>True if trigger is internally generated (usually, to enforce
the constraint identified by <structfield>tgconstraint</>)</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgconstrrelid</structfield></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><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></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
<entry>The table referenced by a referential integrity constraint</entry>
</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>
<entry><structfield>tgconstrindid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The index supporting a unique, primary key, or referential integrity constraint</entry>
</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>
<entry><structfield>tgconstraint</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-constraint"><structname>pg_constraint</structname></link>.oid</literal></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
<entry>The <structname>pg_constraint</> entry associated with the trigger, if any</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgdeferrable</structfield></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><type>bool</type></entry>
<entry></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
<entry>True if constraint trigger is deferrable</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tginitdeferred</structfield></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><type>bool</type></entry>
<entry></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
<entry>True if constraint trigger is initially deferred</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgnargs</structfield></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><type>int2</type></entry>
<entry></entry>
<entry>Number of argument strings passed to trigger function</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgattr</structfield></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><type>int2vector</type></entry>
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
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Column numbers, if trigger is column-specific; otherwise an
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
empty array</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>tgargs</structfield></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><type>bytea</type></entry>
<entry></entry>
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
<entry>Argument strings to pass to trigger, each NULL-terminated</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>
<entry><structfield>tgqual</structfield></entry>
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
<entry><type>pg_node_tree</type></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
<entry></entry>
<entry>Expression tree (in <function>nodeToString()</function>
Spell and markup checking
2010-08-17 06:37:21 +02:00
representation) for the trigger's <literal>WHEN</> condition, or null
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
if none</entry>
</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
<literal>UPDATE</> events, and so <structfield>tgattr</> is relevant
only for that event type. <structfield>tgtype</structfield> might
contain bits for other event types as well, but those are presumed
to be table-wide regardless of what is in <structfield>tgattr</>.
</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>
When <structfield>tgconstraint</> is nonzero,
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
<structfield>tgconstrrelid</>, <structfield>tgconstrindid</>,
<structfield>tgdeferrable</>, and <structfield>tginitdeferred</> are
largely redundant with the referenced <structname>pg_constraint</> entry.
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
described at length in <xref linkend="textsearch">.
</para>
<table>
<title><structname>pg_ts_config</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
<entry><structfield>cfgname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Text search configuration name</entry>
</row>
<row>
<entry><structfield>cfgnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>
The OID of the namespace that contains this configuration
</entry>
</row>
<row>
<entry><structfield>cfgowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the configuration</entry>
</row>
<row>
<entry><structfield>cfgparser</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-ts-parser"><structname>pg_ts_parser</structname></link>.oid</literal></entry>
<entry>The OID of the text search parser for this configuration</entry>
</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
described at length in <xref linkend="textsearch">.
</para>
<table>
<title><structname>pg_ts_config_map</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>mapcfg</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-ts-config"><structname>pg_ts_config</structname></link>.oid</literal></entry>
<entry>The OID of the <structname>pg_ts_config</> entry owning this map entry</entry>
</row>
<row>
<entry><structfield>maptokentype</structfield></entry>
<entry><type>integer</type></entry>
<entry></entry>
<entry>A token type emitted by the configuration's parser</entry>
</row>
<row>
<entry><structfield>mapseqno</structfield></entry>
<entry><type>integer</type></entry>
<entry></entry>
<entry>Order in which to consult this entry (lower
<structfield>mapseqno</>s first)</entry>
</row>
<row>
<entry><structfield>mapdict</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-ts-dict"><structname>pg_ts_dict</structname></link>.oid</literal></entry>
<entry>The OID of the text search dictionary to consult</entry>
</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
are specified by a text string <structfield>dictinitoption</>,
whose format and meaning vary depending on the template.
</para>
<para>
<productname>PostgreSQL</productname>'s text search features are
described at length in <xref linkend="textsearch">.
</para>
<table>
<title><structname>pg_ts_dict</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
<entry><structfield>dictname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Text search dictionary name</entry>
</row>
<row>
<entry><structfield>dictnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>
The OID of the namespace that contains this dictionary
</entry>
</row>
<row>
<entry><structfield>dictowner</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>Owner of the dictionary</entry>
</row>
<row>
<entry><structfield>dicttemplate</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-ts-template"><structname>pg_ts_template</structname></link>.oid</literal></entry>
<entry>The OID of the text search template for this dictionary</entry>
</row>
<row>
<entry><structfield>dictinitoption</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>Initialization option string for the template</entry>
</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
described at length in <xref linkend="textsearch">.
</para>
<table>
<title><structname>pg_ts_parser</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
<entry><structfield>prsname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Text search parser name</entry>
</row>
<row>
<entry><structfield>prsnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>
The OID of the namespace that contains this parser
</entry>
</row>
<row>
<entry><structfield>prsstart</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the parser's startup function</entry>
</row>
<row>
<entry><structfield>prstoken</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the parser's next-token function</entry>
</row>
<row>
<entry><structfield>prsend</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the parser's shutdown function</entry>
</row>
<row>
<entry><structfield>prsheadline</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the parser's headline function</entry>
</row>
<row>
<entry><structfield>prslextype</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the parser's lextype function</entry>
</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
described at length in <xref linkend="textsearch">.
</para>
<table>
<title><structname>pg_ts_template</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</row>
Add catalogs.sgml documentation for text search catalogs.
2007-10-01 23:10:40 +02:00
<row>
<entry><structfield>tmplname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Text search template name</entry>
</row>
<row>
<entry><structfield>tmplnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>
The OID of the namespace that contains this template
</entry>
</row>
<row>
<entry><structfield>tmplinit</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the template's initialization function</entry>
</row>
<row>
<entry><structfield>tmpllexize</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>OID of the template's lexize function</entry>
</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
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-createtype">, and
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
domains with
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
<xref linkend="sql-createdomain">.
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<title><structname>pg_type</> Columns</title>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</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><structfield>typname</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>name</type></entry>
<entry></entry>
<entry>Data type name</entry>
</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typnamespace</structfield></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
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></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
<entry>
The OID of the namespace that contains this type
</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><structfield>typowner</structfield></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
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>Owner of the type</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><structfield>typlen</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>int2</type></entry>
<entry></entry>
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
<entry>
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.
-1 indicates a <quote>varlena</> type (one that has a length word),
-2 indicates a null-terminated C string.
</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><structfield>typbyval</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
<entry>
<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.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typtype</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<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
<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,
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
<literal>p</literal> for a pseudo-type, or
<literal>r</literal> for a range 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>.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</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><structfield>typcategory</structfield></entry>
<entry><type>char</type></entry>
<entry></entry>
<entry>
<structfield>typcategory</structfield> is an arbitrary classification
of data types that is used by the parser to determine which implicit
casts should be <quote>preferred</>.
Spell and markup checking
2010-08-17 06:37:21 +02:00
See <xref linkend="catalog-typcategory-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
</entry>
</row>
<row>
<entry><structfield>typispreferred</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
True if the type is a preferred cast target within its
<structfield>typcategory</structfield>
</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><structfield>typisdefined</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>bool</type></entry>
<entry></entry>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry>
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.
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>
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><structfield>typdelim</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
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
<entry>
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.
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
</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><structfield>typrelid</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<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
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
Update info about relkind and pg_type entries for composite-types patch.
2002-08-28 17:02:55 +02:00
the <structname>pg_class</structname> entry that defines the
corresponding table. (For a free-standing composite type, the
<structname>pg_class</structname> entry doesn't really represent
a table, but it is needed anyway for the type's
<structname>pg_attribute</structname> entries to link to.)
Spell and markup checking
2010-08-17 06:37:21 +02:00
Zero for non-composite types.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typelem</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>oid</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry>
If <structfield>typelem</structfield> is not 0 then it
identifies another row in <structname>pg_type</structname>.
The current type can then be subscripted like an array yielding
Clean up wrong, misleading, or obsolete documentation about array types, particularly in the CREATE TYPE reference page. Fix some other errors in the CREATE TYPE page, too.
2001-11-03 22:42:47 +01:00
values of type <structfield>typelem</structfield>. A
<quote>true</quote> array type is variable length
(<structfield>typlen</structfield> = -1),
but some fixed-length (<structfield>typlen</structfield> &gt; 0) types
also have nonzero <structfield>typelem</structfield>, for example
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
<type>name</type> and <type>point</type>.
Clean up wrong, misleading, or obsolete documentation about array types, particularly in the CREATE TYPE reference page. Fix some other errors in the CREATE TYPE page, too.
2001-11-03 22:42:47 +01:00
If a fixed-length type has a <structfield>typelem</structfield> then
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
its internal representation must be some number of values of the
Spell checking and markup additions
2002-03-22 20:20:45 +01:00
<structfield>typelem</structfield> data type with no other data.
Clean up wrong, misleading, or obsolete documentation about array types, particularly in the CREATE TYPE reference page. Fix some other errors in the CREATE TYPE page, too.
2001-11-03 22:42:47 +01:00
Variable-length array types have a header defined by the array
Spell and markup checking
2010-08-17 06:37:21 +02:00
subroutines.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</entry>
</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>
<entry><structfield>typarray</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
<entry>
If <structfield>typarray</structfield> is not 0 then it
identifies another row in <structname>pg_type</structname>, which
is the <quote>true</quote> array type having this type as element
</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><structfield>typinput</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></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
<entry>Input conversion function (text format)</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><structfield>typoutput</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></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
<entry>Output conversion function (text format)</entry>
</row>
<row>
<entry><structfield>typreceive</structfield></entry>
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></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
<entry>Input conversion function (binary format), or 0 if none</entry>
</row>
<row>
<entry><structfield>typsend</structfield></entry>
<entry><type>regproc</type></entry>
Create <link> entries for the foreign keys in the system catalog chapter. I got tired of hitting the 'up' link, then finding the table in the table of contents, and following it back down. Rod Taylor
2003-06-25 03:14:37 +02:00
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></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
<entry>Output conversion function (binary format), or 0 if none</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>
<entry><structfield>typmodin</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>Type modifier input function, or 0 if type does not support modifiers</entry>
</row>
<row>
<entry><structfield>typmodout</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
<entry>Type modifier output function, or 0 to use the standard format</entry>
</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>
<entry><structfield>typanalyze</structfield></entry>
<entry><type>regproc</type></entry>
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Custom <command>ANALYZE</command> function, or 0 to use the standard function</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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typalign</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<entry><para>
<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
Deprecate 'current' for date/time input. Fix up references to "PostgreSQL" rather than "Postgres". Was roughly evenly split between the two before. ref/ files not yet done.
2001-11-21 06:53:41 +01:00
<productname>PostgreSQL</>.
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.
Proofreading improvements for the Administration documentation book.
2010-02-03 18:25:06 +01:00
</para>
<para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
Possible values are:
<itemizedlist>
<listitem>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>c</> = <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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>s</> = <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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>i</> = <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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>d</> = <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>
</para><note>
<para>
For types used in system tables, it is critical that the size
and alignment defined in <structname>pg_type</structname>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
agree with the way that the compiler will lay out the column in
Spell checking, consistent terminology.
2003-11-01 02:56:29 +01:00
a structure representing a table row.
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</para>
</note></entry>
</row>
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typstorage</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>char</type></entry>
<entry></entry>
<entry><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.
Possible values are
<itemizedlist>
<listitem>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>p</>: Value must always be stored plain.</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
<para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<literal>e</>: Value can be stored in a <quote>secondary</quote>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>m</>: Value can be stored compressed inline.</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
<listitem>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<para><literal>x</>: Value can be stored compressed inline or stored in <quote>secondary</quote> storage.</para>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
</listitem>
</itemizedlist>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Note that <literal>m</> columns can also be moved out to secondary
storage, but only as a last resort (<literal>e</> and <literal>x</> columns are
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
moved first).
</para></entry>
</row>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<row>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typnotnull</structfield></entry>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<entry><type>bool</type></entry>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<entry></entry>
<entry><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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typbasetype</structfield></entry>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<entry><type>oid</type></entry>
Update obsolete examples of error messages; various other minor editing.
2003-09-13 00:17:24 +02:00
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<entry><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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typtypmod</structfield></entry>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<entry><type>int4</type></entry>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<entry></entry>
<entry><para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
Domains use <structfield>typtypmod</structfield> to record the <literal>typmod</>
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
Spell and markup checking
2010-08-17 06:37:21 +02:00
<literal>typmod</>). -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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typndims</structfield></entry>
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<entry><type>int4</type></entry>
<entry></entry>
<entry><para>
<structfield>typndims</structfield> is the number of array dimensions
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
for a domain over an array (that is, <structfield>typbasetype</> is
an array type).
Spell and markup checking
2010-08-17 06:37:21 +02:00
Zero for types other than domains over array types.
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
</para></entry>
</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>
<entry><structfield>typcollation</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-collation"><structname>pg_collation</structname></link>.oid</literal></entry>
<entry><para>
<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
be zero. A base type that supports collations will have
<symbol>DEFAULT_COLLATION_OID</symbol> here. A domain over a
Make a code-cleanup pass over the collations patch. This patch is almost entirely cosmetic --- mostly cleaning up a lot of neglected comments, and fixing code layout problems in places where the patch made lines too long and then pgindent did weird things with that. I did find a bug-of-omission in equalTupleDescs().
2011-04-22 23:43:18 +02:00
collatable type can have some other collation OID, 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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typdefaultbin</structfield></entry>
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
<entry><type>pg_node_tree</type></entry>
Add DOMAIN support. Includes manual pages and regression tests, from Rod Taylor.
2002-03-19 03:18:25 +01:00
<entry></entry>
<entry><para>
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
If <structfield>typdefaultbin</> is not null, it is the
<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>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<entry><structfield>typdefault</structfield></entry>
Rewrite system catalog documentation man page in DocBook with more recent information.
2000-11-29 21:15:59 +01:00
<entry><type>text</type></entry>
<entry></entry>
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
<entry><para>
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<structfield>typdefault</> is null if the type has no associated
default value. If <structfield>typdefaultbin</> is not null,
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
<structfield>typdefault</> must contain a human-readable version of the
default expression represented by <structfield>typdefaultbin</>. If
Add better markup and improve some text here and there.
2003-04-15 15:23:35 +02:00
<structfield>typdefaultbin</> is null and <structfield>typdefault</> is
Code review for DOMAIN patch.
2002-03-20 20:45:13 +01:00
not, then <structfield>typdefault</> 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>
<entry><structfield>typacl</structfield></entry>
<entry><type>aclitem[]</type></entry>
<entry></entry>
<entry>
Access privileges; see
<xref linkend="sql-grant"> and
<xref linkend="sql-revoke">
for details
</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>
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>
<xref linkend="catalog-typcategory-table"> lists the system-defined values
of <structfield>typcategory</>. Any future additions to this list will
also be upper-case ASCII letters. All other ASCII characters are reserved
for user-defined categories.
</para>
<table id="catalog-typcategory-table">
<title><structfield>typcategory</> Codes</title>
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>
<entry><type>unknown</> type</entry>
</row>
</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>
<title><structname>pg_user_mapping</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry></entry>
<entry>Row identifier (hidden attribute; must be explicitly selected)</entry>
</row>
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
<row>
<entry><structfield>umuser</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>OID of the local role being mapped, 0 if the user mapping is public</entry>
</row>
<row>
<entry><structfield>umserver</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.oid</literal></entry>
<entry>
The OID of the foreign server that contains this mapping
</entry>
</row>
<row>
<entry><structfield>umoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
User mapping specific options, as <quote>keyword=value</> strings
Put pg_user_mapping section into the right (alphabetical) order.
2009-02-02 10:49:29 +01:00
</entry>
</row>
</tbody>
</tgroup>
</table>
</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
<sect1 id="views-overview">
<title>System Views</title>
<para>
In addition to the system catalogs, <productname>PostgreSQL</productname>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
provides a number of built-in views. Some system views provide convenient
access to some commonly used queries on the system catalogs. Other views
provide access to internal server state.
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
</para>
<para>
The information schema (<xref linkend="information-schema">) provides
an alternative set of views which overlap the functionality of the system
views. Since the information schema is SQL-standard whereas the views
described here are <productname>PostgreSQL</productname>-specific,
it's usually better to use the information schema if it provides all
the information you need.
</para>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<para>
<xref linkend="view-table"> lists the system views described here.
More detailed documentation of each view follows below.
There are some additional views that provide access to the results of
the statistics collector; they are described in <xref
linkend="monitoring-stats-views-table">.
</para>
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
<para>
Except where noted, all the views described here are read-only.
</para>
<table id="view-table">
<title>System Views</title>
<tgroup cols="2">
<thead>
<row>
<entry>View Name</entry>
<entry>Purpose</entry>
</row>
</thead>
<tbody>
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="view-pg-available-extensions"><structname>pg_available_extensions</structname></link></entry>
<entry>available extensions</entry>
</row>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<row>
<entry><link linkend="view-pg-available-extension-versions"><structname>pg_available_extension_versions</structname></link></entry>
<entry>available versions of extensions</entry>
</row>
Add a new system view, pg_cursors, that displays the currently available cursors. Patch from Joachim Wieland, review and ediorialization by Neil Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or via the Bind message of the frontend/backend protocol. This means the view does not list the unnamed portal or the portal created to implement EXECUTE. Because we do list SPI portals, there might be more rows in this view than you might expect if you are using SPI implicitly (e.g. via a procedural language). Per recent discussion on -hackers, the query string included in the view for cursors defined by DECLARE CURSOR is based on debug_query_string. That means it is not accurate if multiple queries separated by semicolons are submitted as one query string. However, there doesn't seem a trivial fix for that: debug_query_string is better than nothing. I also changed SPI_cursor_open() to include the source text for the portal it creates: AFAICS there is no reason not to do this. Update the documentation and regression tests, bump the catversion.
2006-01-18 07:49:30 +01:00
<row>
<entry><link linkend="view-pg-cursors"><structname>pg_cursors</structname></link></entry>
<entry>open cursors</entry>
</row>
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="view-pg-group"><structname>pg_group</structname></link></entry>
<entry>groups of database users</entry>
</row>
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
<row>
<entry><link linkend="view-pg-indexes"><structname>pg_indexes</structname></link></entry>
<entry>indexes</entry>
</row>
<row>
<entry><link linkend="view-pg-locks"><structname>pg_locks</structname></link></entry>
<entry>currently held locks</entry>
</row>
Add docs for pg_matviews, which were missed in the initial MV commit.
2013-03-06 22:35:59 +01:00
<row>
<entry><link linkend="view-pg-matviews"><structname>pg_matviews</structname></link></entry>
<entry>materialized views</entry>
</row>
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
<row>
<entry><link linkend="view-pg-prepared-statements"><structname>pg_prepared_statements</structname></link></entry>
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
<entry>prepared statements</entry>
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</row>
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
<row>
<entry><link linkend="view-pg-prepared-xacts"><structname>pg_prepared_xacts</structname></link></entry>
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
<entry>prepared transactions</entry>
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +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>
<entry><link linkend="view-pg-roles"><structname>pg_roles</structname></link></entry>
<entry>database roles</entry>
</row>
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
<row>
<entry><link linkend="view-pg-rules"><structname>pg_rules</structname></link></entry>
<entry>rules</entry>
</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="view-pg-seclabels"><structname>pg_seclabels</structname></link></entry>
<entry>security labels</entry>
</row>
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
<row>
<entry><link linkend="view-pg-settings"><structname>pg_settings</structname></link></entry>
<entry>parameter settings</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
<row>
<entry><link linkend="view-pg-shadow"><structname>pg_shadow</structname></link></entry>
<entry>database users</entry>
</row>
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
<row>
<entry><link linkend="view-pg-stats"><structname>pg_stats</structname></link></entry>
<entry>planner statistics</entry>
</row>
<row>
<entry><link linkend="view-pg-tables"><structname>pg_tables</structname></link></entry>
<entry>tables</entry>
</row>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
<row>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
<entry><link linkend="view-pg-timezone-abbrevs"><structname>pg_timezone_abbrevs</structname></link></entry>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
<entry>time zone abbreviations</entry>
</row>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
<row>
<entry><link linkend="view-pg-timezone-names"><structname>pg_timezone_names</structname></link></entry>
<entry>time zone names</entry>
</row>
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
<row>
<entry><link linkend="view-pg-user"><structname>pg_user</structname></link></entry>
<entry>database users</entry>
</row>
Add pg_user_mappings to the table of system views.
2010-10-15 01:12:24 +02:00
<row>
<entry><link linkend="view-pg-user-mappings"><structname>pg_user_mappings</structname></link></entry>
<entry>user mappings</entry>
</row>
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
<row>
<entry><link linkend="view-pg-views"><structname>pg_views</structname></link></entry>
<entry>views</entry>
</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="view-pg-available-extensions">
<title><structname>pg_available_extensions</structname></title>
<indexterm zone="view-pg-available-extensions">
<primary>pg_available_extensions</primary>
</indexterm>
<para>
The <structname>pg_available_extensions</structname> view lists the
Allow non-superusers to create (some) extensions. Remove the unconditional superuser permissions check in CREATE EXTENSION, and instead define a "superuser" extension property, which when false (not the default) skips the superuser permissions check. In this case the calling user only needs enough permissions to execute the commands in the extension's installation script. The superuser property is also enforced in the same way for ALTER EXTENSION UPDATE cases. In other ALTER EXTENSION cases and DROP EXTENSION, test ownership of the extension rather than superuserness. ALTER EXTENSION ADD/DROP needs to insist on ownership of the target object as well; to do that without duplicating code, refactor comment.c's big switch for permissions checks into a separate function in objectaddress.c. I also removed the superuserness checks in pg_available_extensions and related functions; there's no strong reason why everybody shouldn't be able to see that info. Also invent an IF NOT EXISTS variant of CREATE EXTENSION, and use that in pg_dump, so that dumps won't fail for installed-by-default extensions. We don't have any of those yet, but we will soon. This is all per discussion of wrapping the standard procedural languages into extensions. I'll make those changes in a separate commit; this is just putting the core infrastructure in place.
2011-03-04 22:08:24 +01:00
extensions that are available for installation.
See also the
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
<link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>
catalog, which shows the extensions currently installed.
</para>
<table>
<title><structname>pg_available_extensions</> Columns</title>
<tgroup cols="3">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>name</structfield></entry>
<entry><type>name</type></entry>
<entry>Extension name</entry>
</row>
<row>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<entry><structfield>default_version</structfield></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
<entry><type>text</type></entry>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<entry>Name of default version, or <literal>NULL</literal> if none is
specified</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>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<entry><structfield>installed_version</structfield></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
<entry><type>text</type></entry>
<entry>Currently installed version of the extension,
or <literal>NULL</literal> if not installed</entry>
</row>
<row>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<entry><structfield>comment</structfield></entry>
<entry><type>text</type></entry>
<entry>Comment string from the extension's control file</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
The <structname>pg_available_extensions</structname> view is read only.
</para>
</sect1>
<sect1 id="view-pg-available-extension-versions">
<title><structname>pg_available_extension_versions</structname></title>
<indexterm zone="view-pg-available-extension-versions">
<primary>pg_available_extension_versions</primary>
</indexterm>
<para>
The <structname>pg_available_extension_versions</structname> view lists the
Allow non-superusers to create (some) extensions. Remove the unconditional superuser permissions check in CREATE EXTENSION, and instead define a "superuser" extension property, which when false (not the default) skips the superuser permissions check. In this case the calling user only needs enough permissions to execute the commands in the extension's installation script. The superuser property is also enforced in the same way for ALTER EXTENSION UPDATE cases. In other ALTER EXTENSION cases and DROP EXTENSION, test ownership of the extension rather than superuserness. ALTER EXTENSION ADD/DROP needs to insist on ownership of the target object as well; to do that without duplicating code, refactor comment.c's big switch for permissions checks into a separate function in objectaddress.c. I also removed the superuserness checks in pg_available_extensions and related functions; there's no strong reason why everybody shouldn't be able to see that info. Also invent an IF NOT EXISTS variant of CREATE EXTENSION, and use that in pg_dump, so that dumps won't fail for installed-by-default extensions. We don't have any of those yet, but we will soon. This is all per discussion of wrapping the standard procedural languages into extensions. I'll make those changes in a separate commit; this is just putting the core infrastructure in place.
2011-03-04 22:08:24 +01:00
specific extension versions that are available for installation.
See also the <link
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
linkend="catalog-pg-extension"><structname>pg_extension</structname></link>
catalog, which shows the extensions currently installed.
</para>
<table>
<title><structname>pg_available_extension_versions</> Columns</title>
<tgroup cols="3">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>name</structfield></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
<entry><type>name</type></entry>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<entry>Extension name</entry>
</row>
<row>
<entry><structfield>version</structfield></entry>
<entry><type>text</type></entry>
<entry>Version name</entry>
</row>
<row>
<entry><structfield>installed</structfield></entry>
<entry><type>bool</type></entry>
<entry>True if this version of this extension is currently
installed</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>
Allow non-superusers to create (some) extensions. Remove the unconditional superuser permissions check in CREATE EXTENSION, and instead define a "superuser" extension property, which when false (not the default) skips the superuser permissions check. In this case the calling user only needs enough permissions to execute the commands in the extension's installation script. The superuser property is also enforced in the same way for ALTER EXTENSION UPDATE cases. In other ALTER EXTENSION cases and DROP EXTENSION, test ownership of the extension rather than superuserness. ALTER EXTENSION ADD/DROP needs to insist on ownership of the target object as well; to do that without duplicating code, refactor comment.c's big switch for permissions checks into a separate function in objectaddress.c. I also removed the superuserness checks in pg_available_extensions and related functions; there's no strong reason why everybody shouldn't be able to see that info. Also invent an IF NOT EXISTS variant of CREATE EXTENSION, and use that in pg_dump, so that dumps won't fail for installed-by-default extensions. We don't have any of those yet, but we will soon. This is all per discussion of wrapping the standard procedural languages into extensions. I'll make those changes in a separate commit; this is just putting the core infrastructure in place.
2011-03-04 22:08:24 +01:00
<row>
<entry><structfield>superuser</structfield></entry>
<entry><type>bool</type></entry>
<entry>True if only superusers are allowed to install this extension</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><structfield>relocatable</structfield></entry>
<entry><type>bool</type></entry>
<entry>True if extension can be relocated to another schema</entry>
</row>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
<row>
<entry><structfield>schema</structfield></entry>
<entry><type>name</type></entry>
<entry>Name of the schema that the extension must be installed into,
or <literal>NULL</literal> if partially or fully relocatable</entry>
</row>
<row>
<entry><structfield>requires</structfield></entry>
<entry><type>name[]</type></entry>
<entry>Names of prerequisite extensions,
or <literal>NULL</literal> if none</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><structfield>comment</structfield></entry>
<entry><type>text</type></entry>
<entry>Comment string from the extension's control file</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
Rearrange extension-related views as per recent discussion. The original design of pg_available_extensions did not consider the possibility of version-specific control files. Split it into two views: pg_available_extensions shows information that is generic about an extension, while pg_available_extension_versions shows all available versions together with information that could be version-dependent. Also, add an SRF pg_extension_update_paths() to assist in checking that a collection of update scripts provide sane update path sequences.
2011-02-14 22:07:00 +01:00
The <structname>pg_available_extension_versions</structname> view is read
only.
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>
</sect1>
Add a new system view, pg_cursors, that displays the currently available cursors. Patch from Joachim Wieland, review and ediorialization by Neil Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or via the Bind message of the frontend/backend protocol. This means the view does not list the unnamed portal or the portal created to implement EXECUTE. Because we do list SPI portals, there might be more rows in this view than you might expect if you are using SPI implicitly (e.g. via a procedural language). Per recent discussion on -hackers, the query string included in the view for cursors defined by DECLARE CURSOR is based on debug_query_string. That means it is not accurate if multiple queries separated by semicolons are submitted as one query string. However, there doesn't seem a trivial fix for that: debug_query_string is better than nothing. I also changed SPI_cursor_open() to include the source text for the portal it creates: AFAICS there is no reason not to do this. Update the documentation and regression tests, bump the catversion.
2006-01-18 07:49:30 +01:00
<sect1 id="view-pg-cursors">
<title><structname>pg_cursors</structname></title>
<indexterm zone="view-pg-cursors">
<primary>pg_cursors</primary>
</indexterm>
<para>
The <structname>pg_cursors</structname> view lists the cursors that
are currently available. Cursors can be defined in several ways:
<itemizedlist>
<listitem>
<para>
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
via the <xref linkend="sql-declare">
Add a new system view, pg_cursors, that displays the currently available cursors. Patch from Joachim Wieland, review and ediorialization by Neil Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or via the Bind message of the frontend/backend protocol. This means the view does not list the unnamed portal or the portal created to implement EXECUTE. Because we do list SPI portals, there might be more rows in this view than you might expect if you are using SPI implicitly (e.g. via a procedural language). Per recent discussion on -hackers, the query string included in the view for cursors defined by DECLARE CURSOR is based on debug_query_string. That means it is not accurate if multiple queries separated by semicolons are submitted as one query string. However, there doesn't seem a trivial fix for that: debug_query_string is better than nothing. I also changed SPI_cursor_open() to include the source text for the portal it creates: AFAICS there is no reason not to do this. Update the documentation and regression tests, bump the catversion.
2006-01-18 07:49:30 +01:00
statement in SQL
</para>
</listitem>
<listitem>
<para>
via the Bind message in the frontend/backend protocol, as
described in <xref linkend="protocol-flow-ext-query">
</para>
</listitem>
<listitem>
<para>
via the Server Programming Interface (SPI), as described in
<xref linkend="spi-interface">
Fix broken markup.
2006-01-21 20:05:59 +01:00
</para>
</listitem>
Add a new system view, pg_cursors, that displays the currently available cursors. Patch from Joachim Wieland, review and ediorialization by Neil Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or via the Bind message of the frontend/backend protocol. This means the view does not list the unnamed portal or the portal created to implement EXECUTE. Because we do list SPI portals, there might be more rows in this view than you might expect if you are using SPI implicitly (e.g. via a procedural language). Per recent discussion on -hackers, the query string included in the view for cursors defined by DECLARE CURSOR is based on debug_query_string. That means it is not accurate if multiple queries separated by semicolons are submitted as one query string. However, there doesn't seem a trivial fix for that: debug_query_string is better than nothing. I also changed SPI_cursor_open() to include the source text for the portal it creates: AFAICS there is no reason not to do this. Update the documentation and regression tests, bump the catversion.
2006-01-18 07:49:30 +01:00
</itemizedlist>
The <structname>pg_cursors</structname> view displays cursors
created by any of these means. Cursors only exist for the duration
of the transaction that defines them, unless they have been
declared <literal>WITH HOLD</literal>. Therefore non-holdable
cursors are only present in the view until the end of their
creating transaction.
<note>
<para>
Cursors are used internally to implement some of the components
of <productname>PostgreSQL</>, such as procedural languages.
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
Therefore, the <structname>pg_cursors</> view might include cursors
Add a new system view, pg_cursors, that displays the currently available cursors. Patch from Joachim Wieland, review and ediorialization by Neil Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or via the Bind message of the frontend/backend protocol. This means the view does not list the unnamed portal or the portal created to implement EXECUTE. Because we do list SPI portals, there might be more rows in this view than you might expect if you are using SPI implicitly (e.g. via a procedural language). Per recent discussion on -hackers, the query string included in the view for cursors defined by DECLARE CURSOR is based on debug_query_string. That means it is not accurate if multiple queries separated by semicolons are submitted as one query string. However, there doesn't seem a trivial fix for that: debug_query_string is better than nothing. I also changed SPI_cursor_open() to include the source text for the portal it creates: AFAICS there is no reason not to do this. Update the documentation and regression tests, bump the catversion.
2006-01-18 07:49:30 +01:00
that have not been explicitly created by the user.
</para>
</note>
</para>
<table>
<title><structname>pg_cursors</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
Add a new system view, pg_cursors, that displays the currently available cursors. Patch from Joachim Wieland, review and ediorialization by Neil Conway. The view lists cursors defined by DECLARE CURSOR, using SPI, or via the Bind message of the frontend/backend protocol. This means the view does not list the unnamed portal or the portal created to implement EXECUTE. Because we do list SPI portals, there might be more rows in this view than you might expect if you are using SPI implicitly (e.g. via a procedural language). Per recent discussion on -hackers, the query string included in the view for cursors defined by DECLARE CURSOR is based on debug_query_string. That means it is not accurate if multiple queries separated by semicolons are submitted as one query string. However, there doesn't seem a trivial fix for that: debug_query_string is better than nothing. I also changed SPI_cursor_open() to include the source text for the portal it creates: AFAICS there is no reason not to do this. Update the documentation and regression tests, bump the catversion.
2006-01-18 07:49:30 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>name</structfield></entry>
<entry><type>text</type></entry>
<entry>The name of the cursor</entry>
</row>
<row>
<entry><structfield>statement</structfield></entry>
<entry><type>text</type></entry>
<entry>The verbatim query string submitted to declare this cursor</entry>
</row>
<row>
<entry><structfield>is_holdable</structfield></entry>
<entry><type>boolean</type></entry>
<entry>
<literal>true</literal> if the cursor is holdable (that is, it
can be accessed after the transaction that declared the cursor
has committed); <literal>false</literal> otherwise
</entry>
</row>
<row>
<entry><structfield>is_binary</structfield></entry>
<entry><type>boolean</type></entry>
<entry>
<literal>true</literal> if the cursor was declared
<literal>BINARY</literal>; <literal>false</literal>
otherwise
</entry>
</row>
<row>
<entry><structfield>is_scrollable</structfield></entry>
<entry><type>boolean</type></entry>
<entry>
<literal>true</> if the cursor is scrollable (that is, it
allows rows to be retrieved in a nonsequential manner);
<literal>false</literal> otherwise
</entry>
</row>
<row>
<entry><structfield>creation_time</structfield></entry>
<entry><type>timestamptz</type></entry>
<entry>The time at which the cursor was declared</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
The <structname>pg_cursors</structname> view is read only.
</para>
</sect1>
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="view-pg-group">
<title><structname>pg_group</structname></title>
<indexterm zone="view-pg-group">
<primary>pg_group</primary>
</indexterm>
<para>
The view <structname>pg_group</structname> exists for backwards
compatibility: it emulates a catalog that existed in
<productname>PostgreSQL</productname> before version 8.1.
It shows the names and members of all roles that are marked as not
<structfield>rolcanlogin</>, which is an approximation to the set
of roles that are being used as groups.
</para>
<table>
<title><structname>pg_group</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>groname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.rolname</literal></entry>
<entry>Name of the group</entry>
</row>
<row>
<entry><structfield>grosysid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>ID of this group</entry>
</row>
<row>
<entry><structfield>grolist</structfield></entry>
<entry><type>oid[]</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>An array containing the IDs of the roles in this group</entry>
</row>
</tbody>
</tgroup>
</table>
</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
<sect1 id="view-pg-indexes">
<title><structname>pg_indexes</structname></title>
<indexterm zone="view-pg-indexes">
<primary>pg_indexes</primary>
</indexterm>
<para>
The view <structname>pg_indexes</structname> provides access to
useful information about each index in the database.
</para>
<table>
<title><structname>pg_indexes</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>schemaname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.nspname</literal></entry>
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
<entry>Name of schema containing table and index</entry>
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
</row>
<row>
<entry><structfield>tablename</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
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
<entry>Name of table the index is for</entry>
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
</row>
<row>
<entry><structfield>indexname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
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
<entry>Name of index</entry>
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
</row>
Fix pg_indexes view so that it shows the index's tablespace not the parent table's tablespace, as per gripe from Michael Kleiser. Choose a more plausible column order for this view and pg_tables. Update documentation of these views, which was missed in original patch.
2004-10-11 19:24:41 +02:00
<row>
<entry><structfield>tablespace</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.spcname</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Name of tablespace containing index (null if default for database)</entry>
Fix pg_indexes view so that it shows the index's tablespace not the parent table's tablespace, as per gripe from Michael Kleiser. Choose a more plausible column order for this view and pg_tables. Update documentation of these views, which was missed in original patch.
2004-10-11 19:24:41 +02:00
</row>
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
<row>
<entry><structfield>indexdef</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
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
<entry>Index definition (a reconstructed <command>CREATE INDEX</command>
command)</entry>
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
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="view-pg-locks">
<title><structname>pg_locks</structname></title>
<indexterm zone="view-pg-locks">
<primary>pg_locks</primary>
</indexterm>
<para>
The view <structname>pg_locks</structname> provides access to
information about the locks held by open transactions within the
database server. See <xref linkend="mvcc"> for more discussion
of locking.
</para>
<para>
<structname>pg_locks</structname> contains one row per active lockable
object, requested lock mode, and relevant transaction. Thus, the same
Update documentation on may/can/might: Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
lockable object might
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
appear many times, if multiple transactions are holding or waiting
for locks on it. However, an object that currently has no locks on it
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
will not appear at all.
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
</para>
<para>
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
There are several distinct types of lockable objects:
whole relations (e.g., tables), individual pages of relations,
individual tuples of relations,
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
transaction IDs (both virtual and permanent IDs),
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
and general database objects (identified by class OID and object OID,
in the same way as in <structname>pg_description</structname> or
<structname>pg_depend</structname>). Also, the right to extend a
relation is represented as a separate lockable object.
Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.
2011-11-28 19:51:58 +01:00
Also, <quote>advisory</> locks can be taken on numbers that have
user-defined meanings.
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
</para>
<table>
<title><structname>pg_locks</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
<entry><structfield>locktype</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
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
<entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
Type of the lockable object:
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
<literal>relation</>,
<literal>extend</>,
<literal>page</>,
<literal>tuple</>,
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
<literal>transactionid</>,
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
<literal>virtualxid</>,
Fix pg_locks view to call advisory locks advisory locks, while preserving backward compatibility for anyone using the old userlock code that's now on pgfoundry --- locks from that code still show as 'userlock'.
2006-09-23 01:20:14 +02:00
<literal>object</>,
<literal>userlock</>, or
<literal>advisory</>
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
</entry>
</row>
<row>
<entry><structfield>database</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-database"><structname>pg_database</structname></link>.oid</literal></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
OID of the database in which the lock target exists, or
zero if the target is a shared object, or
null if the target is a transaction ID
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</entry>
</row>
<row>
<entry><structfield>relation</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
OID of the relation targeted by the lock, or null if the target is not
a relation or part of a relation
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</entry>
</row>
<row>
<entry><structfield>page</structfield></entry>
<entry><type>integer</type></entry>
<entry></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
Page number targeted by the lock within the relation,
or null if the target is not a relation page or tuple
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</entry>
</row>
<row>
<entry><structfield>tuple</structfield></entry>
<entry><type>smallint</type></entry>
<entry></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
Tuple number targeted by the lock within the page,
or null if the target is not a tuple
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
</entry>
</row>
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
<row>
<entry><structfield>virtualxid</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
Virtual ID of the transaction targeted by the lock,
or null if the target is not a virtual transaction ID
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
</entry>
</row>
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
<row>
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
<entry><structfield>transactionid</structfield></entry>
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
<entry><type>xid</type></entry>
<entry></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
ID of the transaction targeted by the lock,
or null if the target is not a transaction ID
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</entry>
</row>
<row>
<entry><structfield>classid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
OID of the system catalog containing the lock target, or null if the
target is not a general database object
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</entry>
</row>
<row>
<entry><structfield>objid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
OID of the lock target within its system catalog, or null if the
Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.
2011-11-28 19:51:58 +01:00
target is not a general database object
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</entry>
</row>
<row>
<entry><structfield>objsubid</structfield></entry>
<entry><type>smallint</type></entry>
<entry></entry>
<entry>
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
Column number targeted by the lock (the
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
<structfield>classid</> and <structfield>objid</> refer to the
Doc clarification for pg_locks columns. Florian Pflug
2011-07-15 19:12:36 +02:00
table itself),
or zero if the target is some other general database object,
or null if the target is not a general database object
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
</entry>
</row>
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
<row>
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
<entry><structfield>virtualtransaction</structfield></entry>
<entry><type>text</type></entry>
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
<entry></entry>
<entry>
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
Virtual ID of the transaction that is holding or awaiting this lock
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
</entry>
</row>
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
<row>
<entry><structfield>pid</structfield></entry>
<entry><type>integer</type></entry>
<entry></entry>
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
<entry>
Process ID of the server process holding or awaiting this
Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.
2011-11-28 19:51:58 +01:00
lock, or null if the lock is held by a prepared transaction
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
</entry>
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
</row>
<row>
<entry><structfield>mode</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
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
<entry>Name of the lock mode held or desired by this process (see <xref
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
linkend="locking-tables"> and <xref linkend="xact-serializable">)</entry>
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
</row>
<row>
<entry><structfield>granted</structfield></entry>
<entry><type>boolean</type></entry>
<entry></entry>
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
<entry>True if lock is held, false if lock is awaited</entry>
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
</row>
Create a "fast path" for acquiring weak relation locks. When an AccessShareLock, RowShareLock, or RowExclusiveLock is requested on an unshared database relation, and we can verify that no conflicting locks can possibly be present, record the lock in a per-backend queue, stored within the PGPROC, rather than in the primary lock table. This eliminates a great deal of contention on the lock manager LWLocks. This patch also refactors the interface between GetLockStatusData() and pg_lock_status() to be a bit more abstract, so that we don't rely so heavily on the lock manager's internal representation details. The new fast path lock structures don't have a LOCK or PROCLOCK structure to return, so we mustn't depend on that for purposes of listing outstanding locks. Review by Jeff Davis.
2011-05-29 01:52:00 +02:00
<row>
<entry><structfield>fastpath</structfield></entry>
<entry><type>boolean</type></entry>
<entry></entry>
Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.
2011-11-28 19:51:58 +01:00
<entry>True if lock was taken via fast path, false if taken via main
lock table</entry>
Create a "fast path" for acquiring weak relation locks. When an AccessShareLock, RowShareLock, or RowExclusiveLock is requested on an unshared database relation, and we can verify that no conflicting locks can possibly be present, record the lock in a per-backend queue, stored within the PGPROC, rather than in the primary lock table. This eliminates a great deal of contention on the lock manager LWLocks. This patch also refactors the interface between GetLockStatusData() and pg_lock_status() to be a bit more abstract, so that we don't rely so heavily on the lock manager's internal representation details. The new fast path lock structures don't have a LOCK or PROCLOCK structure to return, so we mustn't depend on that for purposes of listing outstanding locks. Review by Jeff Davis.
2011-05-29 01:52:00 +02:00
</row>
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
</tbody>
</tgroup>
</table>
<para>
<structfield>granted</structfield> is true in a row representing a lock
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
held by the indicated transaction. False indicates that this transaction is
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
currently waiting to acquire this lock, which implies that some other
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
transaction is holding a conflicting lock mode on the same lockable object.
The waiting transaction will sleep until the other lock is released (or a
deadlock situation is detected). A single transaction can be waiting to
acquire at most one lock at a time.
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
</para>
<para>
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
Every transaction holds an exclusive lock on its virtual transaction ID for
its entire duration. If a permanent ID is assigned to the transaction
(which normally happens only if the transaction changes the state of the
database), it also holds an exclusive lock on its permanent transaction ID
until it ends. When one transaction finds it necessary to wait specifically
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
for another transaction, it does so by attempting to acquire share lock on
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
the other transaction ID (either virtual or permanent ID depending on the
situation). That will succeed only when the other transaction
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
terminates and releases its locks.
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
</para>
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
<para>
Although tuples are a lockable type of object,
information about row-level locks is stored on disk, not in memory,
and therefore row-level locks normally do not appear in this view.
If a transaction is waiting for a
row-level lock, it will usually appear in the view as waiting for the
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
permanent transaction ID of the current holder of that row lock.
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</para>
<para>
Fix pg_locks view to call advisory locks advisory locks, while preserving backward compatibility for anyone using the old userlock code that's now on pgfoundry --- locks from that code still show as 'userlock'.
2006-09-23 01:20:14 +02:00
Advisory locks can be acquired on keys consisting of either a single
Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.
2011-11-28 19:51:58 +01:00
<type>bigint</type> value or two integer values.
A <type>bigint</type> key is displayed with its
Add built-in userlock manipulation functions to replace the former contrib functionality. Along the way, remove the USER_LOCKS configuration symbol, since it no longer makes any sense to try to compile that out. No user documentation yet ... mmoncure has promised to write some. Thanks to Abhijit Menon-Sen for creating a first draft to work from.
2006-09-19 00:40:40 +02:00
high-order half in the <structfield>classid</> column, its low-order half
in the <structfield>objid</> column, and <structfield>objsubid</> equal
Document how to create advisory lock "bigint" values in SQL. David E. Wheeler
2012-08-28 04:36:37 +02:00
to 1. The original <type>bigint</type> value can be reassembled with the
Update doc mention of how to compute bigint advisory lock value, per Tom Lane's correction.
2012-08-28 18:17:11 +02:00
expression <literal>(classid::bigint &lt;&lt; 32) |
objid::bigint</literal>. Integer keys are displayed with the
Document how to create advisory lock "bigint" values in SQL. David E. Wheeler
2012-08-28 04:36:37 +02:00
first key in the
Add built-in userlock manipulation functions to replace the former contrib functionality. Along the way, remove the USER_LOCKS configuration symbol, since it no longer makes any sense to try to compile that out. No user documentation yet ... mmoncure has promised to write some. Thanks to Abhijit Menon-Sen for creating a first draft to work from.
2006-09-19 00:40:40 +02:00
<structfield>classid</> column, the second key in the <structfield>objid</>
column, and <structfield>objsubid</> equal to 2. The actual meaning of
Fix pg_locks view to call advisory locks advisory locks, while preserving backward compatibility for anyone using the old userlock code that's now on pgfoundry --- locks from that code still show as 'userlock'.
2006-09-23 01:20:14 +02:00
the keys is up to the user. Advisory locks are local to each database,
so the <structfield>database</> column is meaningful for an advisory lock.
Extend the pg_locks system view so that it can fully display all lock types, as per recent discussion.
2005-05-17 23:46:11 +02:00
</para>
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
<para>
<structname>pg_locks</structname> provides a global view of all locks
in the database cluster, not only those relevant to the current database.
Although its <structfield>relation</structfield> column can be joined
against <structname>pg_class</>.<structfield>oid</> to identify locked
relations, this will only work correctly for relations in the current
database (those for which the <structfield>database</structfield> column
is either the current database's OID or zero).
</para>
<para>
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
The <structfield>pid</structfield> column can be joined to the
Further doc cleanups from the pg_stat_activity changes Fujii Masao
2012-01-20 12:23:26 +01:00
<structfield>pid</structfield> column of the
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
<structname>pg_stat_activity</structname> view to get more
Implement lazy XID allocation: transactions that do not modify any database rows will normally never obtain an XID at all. We already did things this way for subtransactions, but this patch extends the concept to top-level transactions. In applications where there are lots of short read-only transactions, this should improve performance noticeably; not so much from removal of the actual XID-assignments, as from reduction of overhead that's driven by the rate of XID consumption. We add a concept of a "virtual transaction ID" so that active transactions can be uniquely identified even if they don't have a regular XID. This is a much lighter-weight concept: uniqueness of VXIDs is only guaranteed over the short term, and no on-disk record is made about them. Florian Pflug, with some editorialization by Tom.
2007-09-05 20:10:48 +02:00
information on the session holding or waiting to hold each lock.
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
Also, if you are using prepared transactions, the
<structfield>transaction</> column can be joined to the
<structfield>transaction</structfield> column of the
<structname>pg_prepared_xacts</structname> view to get more
information on prepared transactions that hold locks.
(A prepared transaction can never be waiting for a lock,
but it continues to hold the locks it acquired while running.)
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
</para>
Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page.
2011-11-28 19:51:58 +01:00
<para>
The <structname>pg_locks</structname> view displays data from both the
regular lock manager and the predicate lock manager, which are
separate systems; in addition, the regular lock manager subdivides its
locks into regular and <firstterm>fast-path</> locks.
This data is not guaranteed to be entirely consistent.
When the view is queried,
data on fast-path locks (with <structfield>fastpath</> = <literal>true</>)
is gathered from each backend one at a time, without freezing the state of
the entire lock manager, so it is possible for locks to be taken or
released while information is gathered. Note, however, that these locks are
known not to conflict with any other lock currently in place. After
all backends have been queried for fast-path locks, the remainder of the
regular lock manager is locked as a unit, and a consistent snapshot of all
remaining locks is collected as an atomic action. After unlocking the
regular lock manager, the predicate lock manager is similarly locked and all
predicate locks are collected as an atomic action. Thus, with the exception
of fast-path locks, each lock manager will deliver a consistent set of
results, but as we do not lock both lock managers simultaneously, it is
possible for locks to be taken or released after we interrogate the regular
lock manager and before we interrogate the predicate lock manager.
</para>
<para>
Locking the regular and/or predicate lock manager could have some
impact on database performance if this view is very frequently accessed.
The locks are held only for the minimum amount of time necessary to
obtain data from the lock managers, but this does not completely eliminate
the possibility of a performance impact.
</para>
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
</sect1>
Add docs for pg_matviews, which were missed in the initial MV commit.
2013-03-06 22:35:59 +01:00
<sect1 id="view-pg-matviews">
<title><structname>pg_matviews</structname></title>
<indexterm zone="view-pg-matviews">
<primary>pg_matviews</primary>
</indexterm>
<indexterm zone="view-pg-matviews">
<primary>materialized views</primary>
</indexterm>
<para>
The view <structname>pg_matviews</structname> provides access to
useful information about each materialized view in the database.
</para>
<table>
<title><structname>pg_matviews</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>schemaname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.nspname</literal></entry>
<entry>Name of schema containing materialized view</entry>
</row>
<row>
<entry><structfield>matviewname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
<entry>Name of materialized view</entry>
</row>
<row>
<entry><structfield>matviewowner</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.rolname</literal></entry>
<entry>Name of materialized view's owner</entry>
</row>
<row>
<entry><structfield>tablespace</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.spcname</literal></entry>
<entry>Name of tablespace containing materialized view (null if default for database)</entry>
</row>
<row>
<entry><structfield>hasindexes</structfield></entry>
<entry><type>boolean</type></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
<entry></entry>
Add docs for pg_matviews, which were missed in the initial MV commit.
2013-03-06 22:35:59 +01:00
<entry>True if materialized view has (or recently had) any indexes</entry>
</row>
<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
<entry><structfield>ispopulated</structfield></entry>
Add docs for pg_matviews, which were missed in the initial MV commit.
2013-03-06 22:35:59 +01:00
<entry><type>boolean</type></entry>
<entry></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
<entry>True if materialized view is currently populated</entry>
Add docs for pg_matviews, which were missed in the initial MV commit.
2013-03-06 22:35:59 +01:00
</row>
<row>
<entry><structfield>definition</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>Materialized view definition (a reconstructed <command>SELECT</command> query)</entry>
</row>
</tbody>
</tgroup>
</table>
</sect1>
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
<sect1 id="view-pg-prepared-statements">
<title><structname>pg_prepared_statements</structname></title>
<indexterm zone="view-pg-prepared-statements">
<primary>pg_prepared_statements</primary>
</indexterm>
<para>
The <structname>pg_prepared_statements</structname> view displays
all the prepared statements that are available in the current
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
session. See <xref linkend="sql-prepare"> for more information about prepared
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
statements.
</para>
<para>
<structname>pg_prepared_statements</structname> contains one row
for each prepared statement. Rows are added to the view when a new
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
prepared statement is created and removed when a prepared statement
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
is released (for example, via the <xref linkend="sql-deallocate"> command).
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</para>
<table>
<title><structname>pg_prepared_statements</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>name</structfield></entry>
<entry><type>text</type></entry>
<entry>
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
The identifier of the prepared statement
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</entry>
</row>
<row>
<entry><structfield>statement</structfield></entry>
<entry><type>text</type></entry>
<entry>
The query string submitted by the client to create this
prepared statement. For prepared statements created via SQL,
this is the <command>PREPARE</command> statement submitted by
the client. For prepared statements created via the
frontend/backend protocol, this is the text of the prepared
Spell and markup checking
2010-08-17 06:37:21 +02:00
statement itself.
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</entry>
</row>
<row>
<entry><structfield>prepare_time</structfield></entry>
<entry><type>timestamptz</type></entry>
<entry>
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
The time at which the prepared statement was created
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</entry>
</row>
<row>
<entry><structfield>parameter_types</structfield></entry>
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
<entry><type>regtype[]</type></entry>
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
<entry>
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
The expected parameter types for the prepared statement in the
form of an array of <type>regtype</type>. The OID corresponding
to an element of this array can be obtained by casting the
Spell and markup checking
2010-08-17 06:37:21 +02:00
<type>regtype</type> value to <type>oid</type>.
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</entry>
</row>
<row>
<entry><structfield>from_sql</structfield></entry>
<entry><type>boolean</type></entry>
<entry>
<literal>true</literal> if the prepared statement was created
via the <command>PREPARE</command> SQL statement;
<literal>false</literal> if the statement was prepared via the
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
frontend/backend protocol
Add a new system view, pg_prepared_statements, that can be used to access information about the prepared statements that are available in the current session. Original patch from Joachim Wieland, various improvements by Neil Conway. The "statement" column of the view contains the literal query string sent by the client, without any rewriting or pretty printing. This means that prepared statements created via SQL will be prefixed with "PREPARE ... AS ", whereas those prepared via the FE/BE protocol will not. That is unfortunate, but discussion on -patches did not yield an efficient way to improve this, and there is some merit in returning exactly what the client sent to the backend. Catalog version bumped, regression tests updated.
2006-01-08 08:00:27 +01:00
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
The <structname>pg_prepared_statements</structname> view is read only.
</para>
</sect1>
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
<sect1 id="view-pg-prepared-xacts">
<title><structname>pg_prepared_xacts</structname></title>
<indexterm zone="view-pg-prepared-xacts">
<primary>pg_prepared_xacts</primary>
</indexterm>
<para>
The view <structname>pg_prepared_xacts</structname> displays
information about transactions that are currently prepared for two-phase
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
commit (see <xref linkend="sql-prepare-transaction"> for details).
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
</para>
<para>
<structname>pg_prepared_xacts</structname> contains one row per prepared
transaction. An entry is removed when the transaction is committed or
rolled back.
</para>
<table>
<title><structname>pg_prepared_xacts</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>transaction</structfield></entry>
<entry><type>xid</type></entry>
<entry></entry>
<entry>
Numeric transaction identifier of the prepared transaction
</entry>
</row>
<row>
<entry><structfield>gid</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>
Global transaction identifier that was assigned to the transaction
</entry>
</row>
Add a time-of-preparation column to the pg_prepared_xacts view, per an old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
2005-06-18 21:33:42 +02:00
<row>
<entry><structfield>prepared</structfield></entry>
<entry><type>timestamp with time zone</type></entry>
<entry></entry>
<entry>
Time at which the transaction was prepared for commit
</entry>
</row>
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
<row>
<entry><structfield>owner</structfield></entry>
<entry><type>name</type></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
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.rolname</literal></entry>
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
<entry>
Name of the user that executed the transaction
</entry>
</row>
<row>
<entry><structfield>database</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-database"><structname>pg_database</structname></link>.datname</literal></entry>
<entry>
Name of the database in which the transaction was executed
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
When the <structname>pg_prepared_xacts</structname> view is accessed, the
internal transaction manager data structures are momentarily locked, and
a copy is made for the view to display. This ensures that the
view produces a consistent set of results, while not blocking
normal operations longer than necessary. Nonetheless
there could be some impact on database performance if this view is
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
frequently accessed.
Two-phase commit. Original patch by Heikki Linnakangas, with additional hacking by Alvaro Herrera and Tom Lane.
2005-06-18 00:32:51 +02:00
</para>
</sect1>
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="view-pg-roles">
<title><structname>pg_roles</structname></title>
<indexterm zone="view-pg-roles">
<primary>pg_roles</primary>
</indexterm>
<para>
The view <structname>pg_roles</structname> provides access to
information about database roles. This is simply a publicly
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType() with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
2008-07-30 19:05:05 +02:00
readable view of
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-authid"><structname>pg_authid</structname></link>
that blanks out the password field.
</para>
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
<para>
This view explicitly exposes the OID column of the underlying table,
since that is needed to do joins to other catalogs.
</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
<table>
<title><structname>pg_roles</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>rolname</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Role name</entry>
</row>
<row>
<entry><structfield>rolsuper</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Role has superuser privileges</entry>
</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>
<entry><structfield>rolinherit</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>Role automatically inherits privileges of roles it is a
member of</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
<row>
<entry><structfield>rolcreaterole</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>Role can create more roles</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>
<entry><structfield>rolcreatedb</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>Role can create databases</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>
<entry><structfield>rolcatupdate</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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 update system catalogs directly. (Even a superuser cannot do
Fix omissions in documentation of the pg_roles view. Somehow, column rolconfig got removed from the documentation of the pg_roles view in the 9.0 cycle, although the column is actually still there. In 9.1, we'd also forgotten to document the rolreplication column. Spotted by Sakamoto Masahiko.
2011-07-04 04:12:14 +02:00
this unless this column is true)
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
</entry>
</row>
<row>
<entry><structfield>rolcanlogin</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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
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
session authorization identifier
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
</entry>
</row>
Fix omissions in documentation of the pg_roles view. Somehow, column rolconfig got removed from the documentation of the pg_roles view in the 9.0 cycle, although the column is actually still there. In 9.1, we'd also forgotten to document the rolreplication column. Spotted by Sakamoto Masahiko.
2011-07-04 04:12:14 +02:00
<row>
<entry><structfield>rolreplication</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
Role is a replication role. That is, this role can initiate streaming
replication (see <xref linkend="streaming-replication">) and set/unset
the system backup mode using <function>pg_start_backup</> and
<function>pg_stop_backup</>
</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>
<entry><structfield>rolconnlimit</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<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
For roles that can log in, this sets maximum number of concurrent
Spell and markup checking
2010-08-17 06:37:21 +02:00
connections this role can make. -1 means no limit.
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
</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
<row>
<entry><structfield>rolpassword</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>Not the password (always reads as <literal>********</>)</entry>
</row>
<row>
<entry><structfield>rolvaliduntil</structfield></entry>
<entry><type>timestamptz</type></entry>
<entry></entry>
<entry>Password expiry time (only used for password authentication);
Spell and markup checking
2010-08-17 06:37:21 +02:00
null if no expiration</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>
Fix omissions in documentation of the pg_roles view. Somehow, column rolconfig got removed from the documentation of the pg_roles view in the 9.0 cycle, although the column is actually still there. In 9.1, we'd also forgotten to document the rolreplication column. Spotted by Sakamoto Masahiko.
2011-07-04 04:12:14 +02:00
<row>
<entry><structfield>rolconfig</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>Role-specific defaults for run-time configuration variables</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
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>
<entry><structfield>oid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>ID of role</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>
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
<sect1 id="view-pg-rules">
<title><structname>pg_rules</structname></title>
<indexterm zone="view-pg-rules">
<primary>pg_rules</primary>
</indexterm>
<para>
The view <structname>pg_rules</structname> provides access to
useful information about query rewrite rules.
</para>
<table>
<title><structname>pg_rules</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>schemaname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.nspname</literal></entry>
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
<entry>Name of schema containing table</entry>
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
</row>
<row>
<entry><structfield>tablename</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
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
<entry>Name of table the rule is for</entry>
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
</row>
<row>
<entry><structfield>rulename</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-rewrite"><structname>pg_rewrite</structname></link>.rulename</literal></entry>
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
<entry>Name of rule</entry>
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
</row>
<row>
<entry><structfield>definition</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
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
<entry>Rule definition (a reconstructed creation command)</entry>
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
</row>
</tbody>
</tgroup>
</table>
<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 <structname>pg_rules</> view excludes the <literal>ON SELECT</> rules
Add docs for pg_matviews, which were missed in the initial MV commit.
2013-03-06 22:35:59 +01:00
of views and materialized views; those can be seen in
<structname>pg_views</> and <structname>pg_matviews</>.
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
</para>
</sect1>
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="view-pg-seclabels">
<title><structname>pg_seclabels</structname></title>
<indexterm zone="view-pg-seclabels">
<primary>pg_seclabels</primary>
</indexterm>
<para>
The view <structname>pg_seclabels</structname> provides information about
security labels. It as an easier-to-query version of the
<link linkend="catalog-pg-seclabel"><structname>pg_seclabel</></> catalog.
</para>
<table>
<title><structname>pg_seclabels</> Columns</title>
<tgroup cols="4">
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>objoid</structfield></entry>
<entry><type>oid</type></entry>
<entry>any OID column</entry>
<entry>The OID of the object this security label pertains to</entry>
</row>
<row>
<entry><structfield>classoid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
<entry>The OID of the system catalog this object appears in</entry>
</row>
<row>
<entry><structfield>objsubid</structfield></entry>
<entry><type>int4</type></entry>
<entry></entry>
<entry>
For a security label on a table column, this is the column number (the
<structfield>objoid</> and <structfield>classoid</> refer to
the table itself). For all other object types, this column is
zero.
</entry>
</row>
<row>
<entry><structfield>objtype</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>
The type of object to which this label applies, as text.
</entry>
</row>
<row>
<entry><structfield>objnamespace</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.oid</literal></entry>
<entry>
The OID of the namespace for this object, if applicable;
otherwise NULL.
</entry>
</row>
<row>
<entry><structfield>objname</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
<entry>
The name of the object to which this label applies, as text.
</entry>
</row>
<row>
<entry><structfield>provider</structfield></entry>
<entry><type>text</type></entry>
<entry><literal><link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link>.provider</literal></entry>
<entry>The label provider associated with this label.</entry>
</row>
<row>
<entry><structfield>label</structfield></entry>
<entry><type>text</type></entry>
<entry><literal><link linkend="catalog-pg-seclabel"><structname>pg_seclabel</structname></link>.label</literal></entry>
<entry>The security label applied to this object.</entry>
</row>
</tbody>
</tgroup>
</table>
</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
<sect1 id="view-pg-settings">
<title><structname>pg_settings</structname></title>
<indexterm zone="view-pg-settings">
<primary>pg_settings</primary>
</indexterm>
<para>
The view <structname>pg_settings</structname> provides access to
run-time parameters of the server. It is essentially an alternative
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
interface to the <xref linkend="sql-show">
and <xref linkend="sql-set"> commands.
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
It also provides access to some facts about each parameter that are
not directly available from <command>SHOW</>, such as minimum and
maximum values.
</para>
<table>
<title><structname>pg_settings</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>name</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Run-time configuration parameter name</entry>
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
</row>
<row>
<entry><structfield>setting</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Current value of the parameter</entry>
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
</row>
Allow units to be specified with configuration settings.
2006-07-27 10:30:41 +02:00
<row>
<entry><structfield>unit</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Implicit unit of the parameter</entry>
Allow units to be specified with configuration settings.
2006-07-27 10:30:41 +02:00
</row>
Documentation update for previously committed changes: read-only GUC variables and pg_settings view.
2003-12-07 00:10:23 +01:00
<row>
<entry><structfield>category</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Logical group of the parameter</entry>
Documentation update for previously committed changes: read-only GUC variables and pg_settings view.
2003-12-07 00:10:23 +01:00
</row>
<row>
<entry><structfield>short_desc</structfield></entry>
<entry><type>text</type></entry>
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
<entry>A brief description of the parameter</entry>
Documentation update for previously committed changes: read-only GUC variables and pg_settings view.
2003-12-07 00:10:23 +01:00
</row>
<row>
<entry><structfield>extra_desc</structfield></entry>
<entry><type>text</type></entry>
Editorial improvements to description of pg_settings view.
2008-10-06 15:59:37 +02:00
<entry>Additional, more detailed, description of the parameter</entry>
Documentation update for previously committed changes: read-only GUC variables and pg_settings view.
2003-12-07 00:10:23 +01:00
</row>
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
<row>
<entry><structfield>context</structfield></entry>
<entry><type>text</type></entry>
Document guc context values, and reference them from the config doc section. Tom Lane
2011-03-17 05:26:03 +01:00
<entry>Context required to set the parameter's value (see below)</entry>
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
</row>
<row>
<entry><structfield>vartype</structfield></entry>
<entry><type>text</type></entry>
Implement enum type for guc parameters, and convert a couple of existing variables to it. More need to be converted, but I wanted to get this in before it conflicts with too much... Other than just centralising the text-to-int conversion for parameters, this allows the pg_settings view to contain a list of available options and allows an error hint to show what values are allowed.
2008-03-10 13:55:13 +01:00
<entry>Parameter type (<literal>bool</>, <literal>enum</>,
<literal>integer</>, <literal>real</>, or <literal>string</>)
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
</entry>
</row>
<row>
<entry><structfield>source</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Source of the current parameter value</entry>
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
</row>
<row>
<entry><structfield>min_val</structfield></entry>
<entry><type>text</type></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Minimum allowed value of the parameter (null for non-numeric
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
values)</entry>
</row>
<row>
<entry><structfield>max_val</structfield></entry>
<entry><type>text</type></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Maximum allowed value of the parameter (null for non-numeric
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
values)</entry>
</row>
Implement enum type for guc parameters, and convert a couple of existing variables to it. More need to be converted, but I wanted to get this in before it conflicts with too much... Other than just centralising the text-to-int conversion for parameters, this allows the pg_settings view to contain a list of available options and allows an error hint to show what values are allowed.
2008-03-10 13:55:13 +01:00
<row>
<entry><structfield>enumvals</structfield></entry>
Docs update for enumvals patch.
2008-11-21 20:31:58 +01:00
<entry><type>text[]</type></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Allowed values of an enum parameter (null for non-enum
Implement enum type for guc parameters, and convert a couple of existing variables to it. More need to be converted, but I wanted to get this in before it conflicts with too much... Other than just centralising the text-to-int conversion for parameters, this allows the pg_settings view to contain a list of available options and allows an error hint to show what values are allowed.
2008-03-10 13:55:13 +01:00
values)</entry>
</row>
Add columns boot_val and reset_val to the pg_settings view, to expose the value a parameter has at server start and will have after RESET, respectively. Greg Smith, with some modifications by me.
2008-10-06 15:05:40 +02:00
<row>
<entry><structfield>boot_val</structfield></entry>
<entry><type>text</type></entry>
<entry>Parameter value assumed at server startup if the parameter is
not otherwise set</entry>
</row>
<row>
<entry><structfield>reset_val</structfield></entry>
<entry><type>text</type></entry>
Editorial improvements to description of pg_settings view.
2008-10-06 15:59:37 +02:00
<entry>Value that <command>RESET</command> would reset the parameter to
in the current session</entry>
Add columns boot_val and reset_val to the pg_settings view, to expose the value a parameter has at server start and will have after RESET, respectively. Greg Smith, with some modifications by me.
2008-10-06 15:05:40 +02:00
</row>
Add "source file" and "source line" information to each GUC variable. initdb forced due to changes in the pg_settings view. Magnus Hagander and Alvaro Herrera.
2008-09-10 20:09:20 +02:00
<row>
<entry><structfield>sourcefile</structfield></entry>
<entry><type>text</type></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Configuration file the current value was set in (null for
Editorial improvements to description of pg_settings view.
2008-10-06 15:59:37 +02:00
values set from sources other than configuration files, or when
Spell and markup checking
2010-08-17 06:37:21 +02:00
examined by a non-superuser);
helpful when using <literal>include</> directives in configuration files</entry>
Add "source file" and "source line" information to each GUC variable. initdb forced due to changes in the pg_settings view. Magnus Hagander and Alvaro Herrera.
2008-09-10 20:09:20 +02:00
</row>
<row>
<entry><structfield>sourceline</structfield></entry>
Editorial improvements to description of pg_settings view.
2008-10-06 15:59:37 +02:00
<entry><type>integer</type></entry>
<entry>Line number within the configuration file the current value was
Spell and markup checking
2010-08-17 06:37:21 +02:00
set at (null for values set from sources other than configuration files,
Editorial improvements to description of pg_settings view.
2008-10-06 15:59:37 +02:00
or when examined by a non-superuser)
Add "source file" and "source line" information to each GUC variable. initdb forced due to changes in the pg_settings view. Magnus Hagander and Alvaro Herrera.
2008-09-10 20:09:20 +02:00
</entry>
</row>
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
</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
Document guc context values, and reference them from the config doc section. Tom Lane
2011-03-17 05:26:03 +01:00
<para>
There are several possible values of <structfield>context</structfield>.
In order of decreasing difficulty of changing the setting, they are:
</para>
<variablelist>
<varlistentry>
<term><literal>internal</literal></term>
<listitem>
<para>
These settings cannot be changed directly; they reflect internally
determined values. Some of them may be adjustable by rebuilding the
server with different configuration options, or by changing options
supplied to <command>initdb</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>postmaster</literal></term>
<listitem>
<para>
These settings can only be applied when the server starts, so any change
requires restarting the server. Values for these settings are typically
stored in the <filename>postgresql.conf</filename> file, or passed on
the command line when starting the server. Of course, settings with any
of the lower <structfield>context</structfield> types can also be
set at server start time.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>sighup</literal></term>
<listitem>
<para>
Changes to these settings can be made in
<filename>postgresql.conf</filename> without restarting the server.
Send a <systemitem>SIGHUP</systemitem> signal to the postmaster to
cause it to re-read <filename>postgresql.conf</filename> and apply
the changes. The postmaster will also forward the
<systemitem>SIGHUP</systemitem> signal to its child processes so that
they all pick up the new value.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>backend</literal></term>
<listitem>
<para>
Changes to these settings can be made in
<filename>postgresql.conf</filename> without restarting the server;
they can also be set for a particular session in the connection request
packet (for example, via <application>libpq</>'s <literal>PGOPTIONS</>
environment variable). However, these settings never change in a
session after it is started. If you change them in
<filename>postgresql.conf</filename>, send a
<systemitem>SIGHUP</systemitem> signal to the postmaster to cause it to
re-read <filename>postgresql.conf</filename>. The new values will only
affect subsequently-launched sessions.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>superuser</literal></term>
<listitem>
<para>
These settings can be set from <filename>postgresql.conf</filename>,
or within a session via the <command>SET</> command; but only superusers
can change them via <command>SET</>. Changes in
<filename>postgresql.conf</filename> will affect existing sessions
only if no session-local value has been established with <command>SET</>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>user</literal></term>
<listitem>
<para>
These settings can be set from <filename>postgresql.conf</filename>,
or within a session via the <command>SET</> command. Any user is
allowed to change his session-local value. Changes in
<filename>postgresql.conf</filename> will affect existing sessions
only if no session-local value has been established with <command>SET</>.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
See <xref linkend="config-setting"> for more information about the various
ways to change these parameters.
</para>
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
<para>
The <structname>pg_settings</structname> view cannot be inserted into or
deleted from, but it can be updated. An <command>UPDATE</command> applied
to a row of <structname>pg_settings</structname> is equivalent to executing
Remove unnecessary xref endterm attributes and title ids The endterm attribute is mainly useful when the toolchain does not support automatic link target text generation for a particular situation. In the past, this was required by the man page tools for all reference page links, but that is no longer the case, and it now actually gets in the way of proper automatic link text generation. The only remaining use cases are currently xrefs to refsects.
2010-04-03 09:23:02 +02:00
the <xref linkend="sql-set"> command on that named
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
parameter. The change only affects the value used by the current
session. If an <command>UPDATE</command> is issued within a transaction
that is later aborted, the effects of the <command>UPDATE</command> command
disappear when the transaction is rolled back. Once the surrounding
transaction is committed, the effects will persist until the end of the
session, unless overridden by another <command>UPDATE</command> or
<command>SET</command>.
</para>
</sect1>
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="view-pg-shadow">
<title><structname>pg_shadow</structname></title>
<indexterm zone="view-pg-shadow">
<primary>pg_shadow</primary>
</indexterm>
<para>
The view <structname>pg_shadow</structname> exists for backwards
compatibility: it emulates a catalog that existed in
<productname>PostgreSQL</productname> before version 8.1.
It shows properties of all roles that are marked as
Link from pg_shadow docs to pg_authid docs. Per discussion with Josh Kupershmidt.
2010-09-13 03:23:35 +02:00
<structfield>rolcanlogin</> in
Elaborate on what gets stored in pg_authid.rolpasswd. Also, add cross-reference from pg_shadow.passwd to pg_authid.rolpasswd and fix a bit of markup I muffed in my previous commit. Per discussion with Josh Kupershmidt.
2010-09-13 19:02:34 +02:00
<link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.
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
</para>
<para>
The name stems from the fact that this table
should not be readable by the public since it contains passwords.
<link linkend="view-pg-user"><structname>pg_user</structname></link>
is a publicly readable view on
<structname>pg_shadow</structname> that blanks out the password field.
</para>
<table>
<title><structname>pg_shadow</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>usename</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.rolname</literal></entry>
<entry>User name</entry>
</row>
<row>
<entry><structfield>usesysid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>ID of this user</entry>
</row>
<row>
<entry><structfield>usecreatedb</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
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
<entry>User can create databases</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>
<entry><structfield>usesuper</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>User is a superuser</entry>
</row>
<row>
<entry><structfield>usecatupd</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
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
User can update system catalogs. (Even a superuser cannot do
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
this unless this column is true.)
</entry>
</row>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
<row>
<entry><structfield>userepl</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>
User can initiate streaming replication and put the system in and
out of backup mode.
</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
<row>
<entry><structfield>passwd</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
Elaborate on what gets stored in pg_authid.rolpasswd. Also, add cross-reference from pg_shadow.passwd to pg_authid.rolpasswd and fix a bit of markup I muffed in my previous commit. Per discussion with Josh Kupershmidt.
2010-09-13 19:02:34 +02:00
<entry>Password (possibly encrypted); null if none. See
<link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>
for details of how encrypted passwords are stored.</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>
<entry><structfield>valuntil</structfield></entry>
<entry><type>abstime</type></entry>
<entry></entry>
<entry>Password expiry time (only used for password authentication)</entry>
</row>
<row>
<entry><structfield>useconfig</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>Session defaults for run-time configuration variables</entry>
</row>
</tbody>
</tgroup>
</table>
</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
<sect1 id="view-pg-stats">
<title><structname>pg_stats</structname></title>
<indexterm zone="view-pg-stats">
<primary>pg_stats</primary>
</indexterm>
<para>
The view <structname>pg_stats</structname> provides access to
the information stored in the <link
linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link>
catalog. This view allows access only to rows of
<structname>pg_statistic</structname> that correspond to tables the
user has permission to read, and therefore it is safe to allow public
read access to this view.
</para>
<para>
<structname>pg_stats</structname> is also designed to present the
information in a more readable format than the underlying catalog
Replace "--" and "---" with "&mdash;" as appropriate, for better-looking output.
2004-11-15 07:32:15 +01:00
&mdash; at the cost that its schema must be extended whenever new slot types
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
are defined for <structname>pg_statistic</structname>.
</para>
<table>
<title><structname>pg_stats</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>schemaname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.nspname</literal></entry>
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
<entry>Name of schema containing table</entry>
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
</row>
<row>
<entry><structfield>tablename</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
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
<entry>Name of table</entry>
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
</row>
<row>
<entry><structfield>attname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attname</literal></entry>
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
<entry>Name of the column described by this row</entry>
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
</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>
<entry><structfield>inherited</structfield></entry>
<entry><type>bool</type></entry>
<entry></entry>
<entry>If true, this row includes inheritance child columns, not just the
values in the specified table</entry>
</row>
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
<row>
<entry><structfield>null_frac</structfield></entry>
<entry><type>real</type></entry>
<entry></entry>
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
<entry>Fraction of column entries that are null</entry>
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
</row>
<row>
<entry><structfield>avg_width</structfield></entry>
<entry><type>integer</type></entry>
<entry></entry>
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
<entry>Average width in bytes of column's entries</entry>
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
</row>
<row>
<entry><structfield>n_distinct</structfield></entry>
<entry><type>real</type></entry>
<entry></entry>
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
<entry>
If greater than zero, the estimated number of distinct values in the
column. If less than zero, the negative of the number of distinct
values divided by the number of rows. (The negated form is used when
<command>ANALYZE</> believes that the number of distinct values is
likely to increase as the table grows; the positive form is used when
the column seems to have a fixed number of possible values.) For
example, -1 indicates a unique column in which the number of distinct
Spell and markup checking
2010-08-17 06:37:21 +02:00
values is the same as the number of rows.
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
</entry>
</row>
<row>
<entry><structfield>most_common_vals</structfield></entry>
<entry><type>anyarray</type></entry>
<entry></entry>
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
<entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
A list of the most common values in the column. (Null if
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
no values seem to be more common than any others.)
</entry>
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
</row>
<row>
<entry><structfield>most_common_freqs</structfield></entry>
<entry><type>real[]</type></entry>
<entry></entry>
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
<entry>
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
A list of the frequencies of the most common values,
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
i.e., number of occurrences of each divided by total number of rows.
Spell and markup checking
2010-08-17 06:37:21 +02:00
(Null when <structfield>most_common_vals</structfield> is.)
Create a type-specific typanalyze routine for tsvector, which collects stats on the most common individual lexemes in place of the mostly-useless default behavior of counting duplicate tsvectors. Future work: create selectivity estimation functions that actually do something with these stats. (Some other things we ought to look at doing: using the Lossy Counting algorithm in compute_minimal_stats, and using the element-counting idea for stats on regular arrays.) Jan Urbanski
2008-07-14 02:51:46 +02:00
</entry>
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
</row>
<row>
<entry><structfield>histogram_bounds</structfield></entry>
<entry><type>anyarray</type></entry>
<entry></entry>
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
<entry>
A list of values that divide the column's values into groups of
approximately equal population. The values in
<structfield>most_common_vals</>, if present, are omitted from this
Spell and markup checking
2010-08-17 06:37:21 +02:00
histogram calculation. (This column is null if the column data type
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
does not have a <literal>&lt;</> operator or if the
<structfield>most_common_vals</> list accounts for the entire
population.)
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
</entry>
</row>
<row>
<entry><structfield>correlation</structfield></entry>
<entry><type>real</type></entry>
<entry></entry>
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
<entry>
Statistical correlation between physical row ordering and
logical ordering of the column values. This ranges from -1 to +1.
When the value is near -1 or +1, an index scan on the column will
be estimated to be cheaper than when it is near zero, due to reduction
Spell and markup checking
2010-08-17 06:37:21 +02:00
of random access to the disk. (This column is null if the column data
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
type does not have a <literal>&lt;</> operator.)
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
</entry>
</row>
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
<row>
<entry><structfield>most_common_elems</structfield></entry>
<entry><type>anyarray</type></entry>
<entry></entry>
<entry>
A list of non-null element values most often appearing within values of
the column. (Null for scalar types.)
</entry>
</row>
<row>
<entry><structfield>most_common_elem_freqs</structfield></entry>
<entry><type>real[]</type></entry>
<entry></entry>
<entry>
A list of the frequencies of the most common element values, i.e., the
fraction of rows containing at least one instance of the given value.
Two or three additional values follow the per-element frequencies;
these are the minimum and maximum of the preceding per-element
frequencies, and optionally the frequency of null elements.
(Null when <structfield>most_common_elems</structfield> is.)
</entry>
</row>
<row>
<entry><structfield>elem_count_histogram</structfield></entry>
<entry><type>real[]</type></entry>
<entry></entry>
<entry>
A histogram of the counts of distinct non-null element values within the
values of the column, followed by the average number of distinct
non-null elements. (Null for scalar types.)
</entry>
</row>
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
</tbody>
</tgroup>
</table>
<para>
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
The maximum number of entries in the array fields can be controlled on a
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
column-by-column basis using the <command>ALTER TABLE SET STATISTICS</>
command, or globally by setting the
Spellchecking run, final cleanups
2005-11-05 00:14:02 +01:00
<xref linkend="guc-default-statistics-target"> run-time parameter.
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
</para>
</sect1>
<sect1 id="view-pg-tables">
<title><structname>pg_tables</structname></title>
<indexterm zone="view-pg-tables">
<primary>pg_tables</primary>
</indexterm>
<para>
The view <structname>pg_tables</structname> provides access to
useful information about each table in the database.
</para>
<table>
<title><structname>pg_tables</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>schemaname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.nspname</literal></entry>
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
<entry>Name of schema containing table</entry>
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
</row>
<row>
<entry><structfield>tablename</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
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
<entry>Name of table</entry>
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
</row>
<row>
<entry><structfield>tableowner</structfield></entry>
<entry><type>name</type></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
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.rolname</literal></entry>
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
<entry>Name of table's owner</entry>
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
</row>
Fix pg_indexes view so that it shows the index's tablespace not the parent table's tablespace, as per gripe from Michael Kleiser. Choose a more plausible column order for this view and pg_tables. Update documentation of these views, which was missed in original patch.
2004-10-11 19:24:41 +02:00
<row>
<entry><structfield>tablespace</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.spcname</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>Name of tablespace containing table (null if default for database)</entry>
Fix pg_indexes view so that it shows the index's tablespace not the parent table's tablespace, as per gripe from Michael Kleiser. Choose a more plausible column order for this view and pg_tables. Update documentation of these views, which was missed in original patch.
2004-10-11 19:24:41 +02:00
</row>
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
<row>
<entry><structfield>hasindexes</structfield></entry>
<entry><type>boolean</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relhasindex</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>True if table has (or recently had) any indexes</entry>
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
</row>
<row>
<entry><structfield>hasrules</structfield></entry>
<entry><type>boolean</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relhasrules</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>True if table has (or once had) rules</entry>
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
</row>
<row>
<entry><structfield>hastriggers</structfield></entry>
<entry><type>boolean</type></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
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relhastriggers</literal></entry>
Spell and markup checking
2010-08-17 06:37:21 +02:00
<entry>True if table has (or once had) triggers</entry>
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
</row>
</tbody>
</tgroup>
</table>
</sect1>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
<sect1 id="view-pg-timezone-abbrevs">
<title><structname>pg_timezone_abbrevs</structname></title>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
<indexterm zone="view-pg-timezone-abbrevs">
<primary>pg_timezone_abbrevs</primary>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
</indexterm>
<para>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
The view <structname>pg_timezone_abbrevs</structname> provides a list
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
of time zone abbreviations that are currently recognized by the datetime
input routines. The contents of this view change when the
<xref linkend="guc-timezone-abbreviations"> run-time parameter is modified.
</para>
<table>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
<title><structname>pg_timezone_abbrevs</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>abbrev</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Time zone abbreviation</entry>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
</row>
<row>
<entry><structfield>utc_offset</structfield></entry>
<entry><type>interval</type></entry>
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
<entry>Offset from UTC (positive means east of Greenwich)</entry>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
</row>
<row>
<entry><structfield>is_dst</structfield></entry>
<entry><type>boolean</type></entry>
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
<entry>True if this is a daylight-savings abbreviation</entry>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
</row>
</tbody>
</tgroup>
</table>
</sect1>
<sect1 id="view-pg-timezone-names">
<title><structname>pg_timezone_names</structname></title>
<indexterm zone="view-pg-timezone-names">
<primary>pg_timezone_names</primary>
</indexterm>
<para>
The view <structname>pg_timezone_names</structname> provides a list
of time zone names that are recognized by <command>SET TIMEZONE</>,
along with their associated abbreviations, UTC offsets,
Add mention that UTC really means UT1. Backpatch to 9.1.
2011-09-05 21:37:58 +02:00
and daylight-savings status. (Technically,
<productname>PostgreSQL</productname> uses <acronym>UT1</> rather
than UTC because leap seconds are not handled.)
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
Unlike the abbreviations shown in <link
linkend="view-pg-timezone-abbrevs"><structname>pg_timezone_abbrevs</structname></link>, many of these names imply a set of daylight-savings transition
date rules. Therefore, the associated information changes across local DST
boundaries. The displayed information is computed based on the current
value of <function>CURRENT_TIMESTAMP</>.
</para>
<table>
<title><structname>pg_timezone_names</> Columns</title>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>name</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Time zone name</entry>
Rename the recently-added pg_timezonenames view to pg_timezone_abbrevs, and create a new view pg_timezone_names that provides information about the zones known in the 'zic' database. Magnus Hagander, with some additional work by Tom Lane.
2006-09-16 22:14:34 +02:00
</row>
<row>
<entry><structfield>abbrev</structfield></entry>
<entry><type>text</type></entry>
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
<entry>Time zone abbreviation</entry>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
</row>
<row>
<entry><structfield>utc_offset</structfield></entry>
<entry><type>interval</type></entry>
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
<entry>Offset from UTC (positive means east of Greenwich)</entry>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
</row>
<row>
<entry><structfield>is_dst</structfield></entry>
<entry><type>boolean</type></entry>
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
<entry>True if currently observing daylight savings</entry>
Remove hard-wired lists of timezone abbreviations in favor of providing configuration files that can be altered by a DBA. The australian_timezones GUC setting disappears, replaced by a timezone_abbreviations setting (set this to 'Australia' to get the effect of australian_timezones). The list of zone names defined by default has undergone a bit of cleanup, too. Documentation still needs some work --- in particular, should we fix Table B-4, or just get rid of it? Joachim Wieland, with some editorializing by moi.
2006-07-25 05:51:23 +02:00
</row>
</tbody>
</tgroup>
</table>
</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
<sect1 id="view-pg-user">
<title><structname>pg_user</structname></title>
<indexterm zone="view-pg-user">
<primary>pg_user</primary>
</indexterm>
<para>
The view <structname>pg_user</structname> provides access to
information about database users. This is simply a publicly
Replace the hard-wired type knowledge in TypeCategory() and IsPreferredType() with system catalog lookups, as was foreseen to be necessary almost since their creation. Instead put the information into two new pg_type columns, typcategory and typispreferred. Add support for setting these when creating a user-defined base type. The category column is just a "char" (i.e. a poor man's enum), allowing a crude form of user extensibility of the category list: just use an otherwise-unused character. This seems sufficient for foreseen uses, but we could upgrade to having an actual category catalog someday, if there proves to be a huge demand for custom type categories. In this patch I have attempted to hew exactly to the behavior of the previous hardwired logic, except for introducing new type categories for arrays, composites, and enums. In particular the default preferred state for user-defined types remains TRUE. That seems worth revisiting, but it should be done as a separate patch from introducing the infrastructure. Likewise, any adjustment of the standard set of categories should be done separately.
2008-07-30 19:05:05 +02:00
readable view of
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="view-pg-shadow"><structname>pg_shadow</structname></link>
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
that blanks out the password field.
</para>
<table>
<title><structname>pg_user</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="3">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>usename</structfield></entry>
<entry><type>name</type></entry>
<entry>User name</entry>
</row>
<row>
<entry><structfield>usesysid</structfield></entry>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
<entry><type>oid</type></entry>
<entry>ID of this user</entry>
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
</row>
<row>
<entry><structfield>usecreatedb</structfield></entry>
<entry><type>bool</type></entry>
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
<entry>User can create databases</entry>
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
</row>
<row>
<entry><structfield>usesuper</structfield></entry>
<entry><type>bool</type></entry>
<entry>User is a superuser</entry>
</row>
<row>
<entry><structfield>usecatupd</structfield></entry>
<entry><type>bool</type></entry>
<entry>
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
User can update system catalogs. (Even a superuser cannot do
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
this unless this column is true.)
</entry>
</row>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
<row>
<entry><structfield>userepl</structfield></entry>
<entry><type>bool</type></entry>
<entry>
User can initiate streaming replication and put the system in and
out of backup mode.
</entry>
</row>
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
<row>
<entry><structfield>passwd</structfield></entry>
<entry><type>text</type></entry>
<entry>Not the password (always reads as <literal>********</>)</entry>
</row>
<row>
<entry><structfield>valuntil</structfield></entry>
<entry><type>abstime</type></entry>
More minor updates and copy-editing.
2005-01-06 00:42:03 +01:00
<entry>Password expiry time (only used for password authentication)</entry>
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
</row>
<row>
<entry><structfield>useconfig</structfield></entry>
<entry><type>text[]</type></entry>
<entry>Session defaults for run-time configuration variables</entry>
</row>
</tbody>
</tgroup>
</table>
</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="view-pg-user-mappings">
<title><structname>pg_user_mappings</structname></title>
<indexterm zone="view-pg-user-mappings">
<primary>pg_user_mappings</primary>
</indexterm>
<para>
The view <structname>pg_user_mappings</structname> provides access
to information about user mappings. This is essentially a publicly
readable view of
<link linkend="catalog-pg-user-mapping"><structname>pg_user_mapping</structname></link>
that leaves out the options field if the user has no rights to use
it.
</para>
<table>
<title><structname>pg_user_mappings</> Columns</title>
Fix number of columns declared for pg_user_mappings description table.
2009-08-11 00:13:50 +02:00
<tgroup cols="4">
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>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>umid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-user-mapping"><structname>pg_user_mapping</structname></link>.oid</literal></entry>
<entry>OID of the user mapping</entry>
</row>
<row>
<entry><structfield>srvid</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.oid</literal></entry>
<entry>
The OID of the foreign server that contains this mapping
</entry>
</row>
<row>
<entry><structfield>srvname</structfield></entry>
Correct various system catalog/view definitions in the documentation Thom Brown
2012-04-06 22:54:27 +02:00
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-foreign-server"><structname>pg_foreign_server</structname></link>.srvname</literal></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
<entry>
Name of the foreign server
</entry>
</row>
<row>
<entry><structfield>umuser</structfield></entry>
<entry><type>oid</type></entry>
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
<entry>OID of the local role being mapped, 0 if the user mapping is public</entry>
</row>
<row>
<entry><structfield>usename</structfield></entry>
<entry><type>name</type></entry>
<entry></entry>
<entry>Name of the local user to be mapped</entry>
</row>
<row>
<entry><structfield>umoptions</structfield></entry>
<entry><type>text[]</type></entry>
<entry></entry>
<entry>
User mapping specific options, as <quote>keyword=value</>
strings, if the current user is the owner of the foreign
Spell and markup checking
2010-08-17 06:37:21 +02:00
server, else null
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
</entry>
</row>
</tbody>
</tgroup>
</table>
</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
<sect1 id="view-pg-views">
<title><structname>pg_views</structname></title>
<indexterm zone="view-pg-views">
<primary>pg_views</primary>
</indexterm>
<para>
The view <structname>pg_views</structname> provides access to
useful information about each view in the database.
</para>
<table>
<title><structname>pg_views</> Columns</title>
Fix some SGML-compiler warnings on -wxml mode.
2009-02-04 22:30:41 +01:00
<tgroup cols="4">
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
<thead>
<row>
<entry>Name</entry>
<entry>Type</entry>
<entry>References</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><structfield>schemaname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-namespace"><structname>pg_namespace</structname></link>.nspname</literal></entry>
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
<entry>Name of schema containing view</entry>
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
</row>
<row>
<entry><structfield>viewname</structfield></entry>
<entry><type>name</type></entry>
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relname</literal></entry>
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
<entry>Name of view</entry>
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
</row>
<row>
<entry><structfield>viewowner</structfield></entry>
<entry><type>name</type></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
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.rolname</literal></entry>
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
<entry>Name of view's owner</entry>
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
</row>
<row>
<entry><structfield>definition</structfield></entry>
<entry><type>text</type></entry>
<entry></entry>
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
<entry>View definition (a reconstructed <command>SELECT</command> query)</entry>
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
</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>