1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* pg_class.h
|
2018-04-19 23:14:09 +02:00
|
|
|
* definition of the "relation" system catalog (pg_class)
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/pg_class.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
* NOTES
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
* The Catalog.pm module reads this file and derives schema
|
|
|
|
* information.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2000-06-17 06:56:39 +02:00
|
|
|
#ifndef PG_CLASS_H
|
|
|
|
#define PG_CLASS_H
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2008-03-27 04:57:34 +01:00
|
|
|
#include "catalog/genbki.h"
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
#include "catalog/pg_class_d.h"
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* pg_class definition. cpp turns this into
|
|
|
|
* typedef struct FormData_pg_class
|
2020-02-15 20:57:27 +01:00
|
|
|
*
|
|
|
|
* Note that the BKI_DEFAULT values below are only used for rows describing
|
|
|
|
* BKI_BOOTSTRAP catalogs, since only those rows appear in pg_class.dat.
|
1996-08-28 03:59:28 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
CATALOG(pg_class,1259,RelationRelationId) BKI_BOOTSTRAP BKI_ROWTYPE_OID(83,RelationRelation_Rowtype_Id) BKI_SCHEMA_MACRO
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2019-03-12 17:30:35 +01:00
|
|
|
/* oid */
|
|
|
|
Oid oid;
|
2010-02-26 03:01:40 +01:00
|
|
|
|
2019-03-12 17:30:35 +01:00
|
|
|
/* class name */
|
|
|
|
NameData relname;
|
|
|
|
|
|
|
|
/* OID of namespace containing this class */
|
|
|
|
Oid relnamespace BKI_DEFAULT(PGNSP);
|
|
|
|
|
|
|
|
/* OID of entry in pg_type for table's implicit row type */
|
|
|
|
Oid reltype BKI_LOOKUP(pg_type);
|
|
|
|
|
|
|
|
/* OID of entry in pg_type for underlying composite type */
|
|
|
|
Oid reloftype BKI_DEFAULT(0) BKI_LOOKUP(pg_type);
|
|
|
|
|
|
|
|
/* class owner */
|
|
|
|
Oid relowner BKI_DEFAULT(PGUID);
|
|
|
|
|
|
|
|
/* access method; 0 if not a table / index */
|
2020-02-15 20:57:27 +01:00
|
|
|
Oid relam BKI_DEFAULT(heap) BKI_LOOKUP(pg_am);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* identifier of physical storage file */
|
2010-02-07 21:48:13 +01:00
|
|
|
/* relfilenode == 0 means it is a "mapped" relation, see relmapper.c */
|
2020-02-15 20:57:27 +01:00
|
|
|
Oid relfilenode BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* identifier of table space for relation (0 means default for database) */
|
|
|
|
Oid reltablespace BKI_DEFAULT(0) BKI_LOOKUP(pg_tablespace);
|
|
|
|
|
|
|
|
/* # of blocks (not always up-to-date) */
|
2020-02-15 20:57:27 +01:00
|
|
|
int32 relpages BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* # of tuples (not always up-to-date) */
|
2020-02-15 20:57:27 +01:00
|
|
|
float4 reltuples BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* # of all-visible blocks (not always up-to-date) */
|
2020-02-15 20:57:27 +01:00
|
|
|
int32 relallvisible BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* OID of toast table; 0 if none */
|
2020-02-15 20:57:27 +01:00
|
|
|
Oid reltoastrelid BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* T if has (or has had) any indexes */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relhasindex BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* T if shared across databases */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relisshared BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* see RELPERSISTENCE_xxx constants below */
|
2020-02-15 20:57:27 +01:00
|
|
|
char relpersistence BKI_DEFAULT(p);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* see RELKIND_xxx constants below */
|
2020-02-15 20:57:27 +01:00
|
|
|
char relkind BKI_DEFAULT(r);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* number of user attributes */
|
2020-02-15 20:57:27 +01:00
|
|
|
int16 relnatts BKI_DEFAULT(0); /* genbki.pl will fill this in */
|
2001-10-25 07:50:21 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2001-08-10 20:57:42 +02:00
|
|
|
* Class pg_attribute must contain exactly "relnatts" user attributes
|
2005-10-15 04:49:52 +02:00
|
|
|
* (with attnums ranging from 1 to relnatts) for this class. It may also
|
|
|
|
* contain entries with negative attnums for system attributes.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* # of CHECK constraints for class */
|
2020-02-15 20:57:27 +01:00
|
|
|
int16 relchecks BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* has (or has had) any rules */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relhasrules BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* has (or has had) any TRIGGERs */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relhastriggers BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* has (or has had) child tables or indexes */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relhassubclass BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* row security is enabled or not */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relrowsecurity BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* row security forced for owners or not */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relforcerowsecurity BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* matview currently holds query results */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relispopulated BKI_DEFAULT(t);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* see REPLICA_IDENTITY_xxx constants */
|
2020-02-15 20:57:27 +01:00
|
|
|
char relreplident BKI_DEFAULT(n);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* is relation a partition? */
|
2020-02-15 20:57:27 +01:00
|
|
|
bool relispartition BKI_DEFAULT(f);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* heap for rewrite during DDL, link to original rel */
|
2019-03-14 21:25:39 +01:00
|
|
|
Oid relrewrite BKI_DEFAULT(0);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* all Xids < this are frozen in this rel */
|
2020-02-15 20:57:27 +01:00
|
|
|
TransactionId relfrozenxid BKI_DEFAULT(3); /* FirstNormalTransactionId */
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* all multixacts in this rel are >= this; it is really a MultiXactId */
|
2020-02-15 20:57:27 +01:00
|
|
|
TransactionId relminmxid BKI_DEFAULT(1); /* FirstMultiXactId */
|
2001-10-25 07:50:21 +02:00
|
|
|
|
2012-01-27 19:16:17 +01:00
|
|
|
#ifdef CATALOG_VARLEN /* variable-length fields start here */
|
|
|
|
/* NOTE: These fields are not present in a relcache entry's rd_rel field. */
|
2019-03-12 17:30:35 +01:00
|
|
|
/* access permissions */
|
2020-02-15 20:57:27 +01:00
|
|
|
aclitem relacl[1] BKI_DEFAULT(_null_);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* access-method-specific options */
|
2020-02-15 20:57:27 +01:00
|
|
|
text reloptions[1] BKI_DEFAULT(_null_);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
/* partition bound node tree */
|
2020-02-15 20:57:27 +01:00
|
|
|
pg_node_tree relpartbound BKI_DEFAULT(_null_);
|
2012-01-27 19:16:17 +01:00
|
|
|
#endif
|
1996-08-28 03:59:28 +02:00
|
|
|
} FormData_pg_class;
|
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
/* Size of fixed part of pg_class tuples, not counting var-length fields */
|
1996-08-28 03:59:28 +02:00
|
|
|
#define CLASS_TUPLE_SIZE \
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
(offsetof(FormData_pg_class,relminmxid) + sizeof(TransactionId))
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/* ----------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Form_pg_class corresponds to a pointer to a tuple with
|
|
|
|
* the format of pg_class relation.
|
1996-08-28 03:59:28 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef FormData_pg_class *Form_pg_class;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
#ifdef EXPOSE_TO_CLIENT_CODE
|
2011-02-23 01:23:23 +01:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#define RELKIND_RELATION 'r' /* ordinary table */
|
|
|
|
#define RELKIND_INDEX 'i' /* secondary index */
|
|
|
|
#define RELKIND_SEQUENCE 'S' /* sequence object */
|
|
|
|
#define RELKIND_TOASTVALUE 't' /* for out-of-line values */
|
|
|
|
#define RELKIND_VIEW 'v' /* view */
|
|
|
|
#define RELKIND_MATVIEW 'm' /* materialized view */
|
|
|
|
#define RELKIND_COMPOSITE_TYPE 'c' /* composite type */
|
|
|
|
#define RELKIND_FOREIGN_TABLE 'f' /* foreign table */
|
|
|
|
#define RELKIND_PARTITIONED_TABLE 'p' /* partitioned table */
|
Local partitioned indexes
When CREATE INDEX is run on a partitioned table, create catalog entries
for an index on the partitioned table (which is just a placeholder since
the table proper has no data of its own), and recurse to create actual
indexes on the existing partitions; create them in future partitions
also.
As a convenience gadget, if the new index definition matches some
existing index in partitions, these are picked up and used instead of
creating new ones. Whichever way these indexes come about, they become
attached to the index on the parent table and are dropped alongside it,
and cannot be dropped on isolation unless they are detached first.
To support pg_dump'ing these indexes, add commands
CREATE INDEX ON ONLY <table>
(which creates the index on the parent partitioned table, without
recursing) and
ALTER INDEX ATTACH PARTITION
(which is used after the indexes have been created individually on each
partition, to attach them to the parent index). These reconstruct prior
database state exactly.
Reviewed-by: (in alphabetical order) Peter Eisentraut, Robert Haas, Amit
Langote, Jesper Pedersen, Simon Riggs, David Rowley
Discussion: https://postgr.es/m/20171113170646.gzweigyrgg6pwsg4@alvherre.pgsql
2018-01-19 15:49:22 +01:00
|
|
|
#define RELKIND_PARTITIONED_INDEX 'I' /* partitioned index */
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
|
|
|
|
#define RELPERSISTENCE_PERMANENT 'p' /* regular table */
|
|
|
|
#define RELPERSISTENCE_UNLOGGED 'u' /* unlogged permanent table */
|
|
|
|
#define RELPERSISTENCE_TEMP 't' /* temporary table */
|
2010-12-13 18:34:26 +01:00
|
|
|
|
2013-11-08 18:30:43 +01:00
|
|
|
/* default selection for replica identity (primary key or nothing) */
|
|
|
|
#define REPLICA_IDENTITY_DEFAULT 'd'
|
|
|
|
/* no replica identity is logged for this relation */
|
|
|
|
#define REPLICA_IDENTITY_NOTHING 'n'
|
2015-06-10 08:26:02 +02:00
|
|
|
/* all columns are logged as replica identity */
|
2013-11-08 18:30:43 +01:00
|
|
|
#define REPLICA_IDENTITY_FULL 'f'
|
|
|
|
/*
|
2017-03-10 19:15:47 +01:00
|
|
|
* an explicitly chosen candidate key's columns are used as replica identity.
|
|
|
|
* Note this will still be set if the index has been dropped; in that case it
|
|
|
|
* has the same meaning as 'd'.
|
2013-11-08 18:30:43 +01:00
|
|
|
*/
|
|
|
|
#define REPLICA_IDENTITY_INDEX 'i'
|
2017-03-10 19:15:47 +01:00
|
|
|
|
2018-12-17 19:37:40 +01:00
|
|
|
/*
|
|
|
|
* Relation kinds that have physical storage. These relations normally have
|
|
|
|
* relfilenode set to non-zero, but it can also be zero if the relation is
|
|
|
|
* mapped.
|
|
|
|
*/
|
2019-01-04 18:34:18 +01:00
|
|
|
#define RELKIND_HAS_STORAGE(relkind) \
|
2018-12-17 19:37:40 +01:00
|
|
|
((relkind) == RELKIND_RELATION || \
|
|
|
|
(relkind) == RELKIND_INDEX || \
|
|
|
|
(relkind) == RELKIND_SEQUENCE || \
|
|
|
|
(relkind) == RELKIND_TOASTVALUE || \
|
|
|
|
(relkind) == RELKIND_MATVIEW)
|
|
|
|
|
|
|
|
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
#endif /* EXPOSE_TO_CLIENT_CODE */
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* PG_CLASS_H */
|