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
|
|
|
*
|
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, 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
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
|
* 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
|
1996-08-28 03:59:28 +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 */
|
2021-02-03 18:01:48 +01:00
|
|
|
Oid relnamespace BKI_DEFAULT(pg_catalog) BKI_LOOKUP(pg_namespace);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
Build in some knowledge about foreign-key relationships in the catalogs.
This follows in the spirit of commit dfb75e478, which created primary
key and uniqueness constraints to improve the visibility of constraints
imposed on the system catalogs. While our catalogs contain many
foreign-key-like relationships, they don't quite follow SQL semantics,
in that the convention for an omitted reference is to write zero not
NULL. Plus, we have some cases in which there are arrays each of whose
elements is supposed to be an FK reference; SQL has no way to model that.
So we can't create actual foreign key constraints to describe the
situation. Nonetheless, we can collect and use knowledge about these
relationships.
This patch therefore adds annotations to the catalog header files to
declare foreign-key relationships. (The BKI_LOOKUP annotations cover
simple cases, but we weren't previously distinguishing which such
columns are allowed to contain zeroes; we also need new markings for
multi-column FK references.) Then, Catalog.pm and genbki.pl are
taught to collect this information into a table in a new generated
header "system_fk_info.h". The only user of that at the moment is
a new SQL function pg_get_catalog_foreign_keys(), which exposes the
table to SQL. The oidjoins regression test is rewritten to use
pg_get_catalog_foreign_keys() to find out which columns to check.
Aside from removing the need for manual maintenance of that test
script, this allows it to cover numerous relationships that were not
checked by the old implementation based on findoidjoins. (As of this
commit, 217 relationships are checked by the test, versus 181 before.)
Discussion: https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us
2021-02-02 23:11:55 +01:00
|
|
|
/* OID of entry in pg_type for relation's implicit row type, if any */
|
|
|
|
|
Oid reltype BKI_LOOKUP_OPT(pg_type);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
Build in some knowledge about foreign-key relationships in the catalogs.
This follows in the spirit of commit dfb75e478, which created primary
key and uniqueness constraints to improve the visibility of constraints
imposed on the system catalogs. While our catalogs contain many
foreign-key-like relationships, they don't quite follow SQL semantics,
in that the convention for an omitted reference is to write zero not
NULL. Plus, we have some cases in which there are arrays each of whose
elements is supposed to be an FK reference; SQL has no way to model that.
So we can't create actual foreign key constraints to describe the
situation. Nonetheless, we can collect and use knowledge about these
relationships.
This patch therefore adds annotations to the catalog header files to
declare foreign-key relationships. (The BKI_LOOKUP annotations cover
simple cases, but we weren't previously distinguishing which such
columns are allowed to contain zeroes; we also need new markings for
multi-column FK references.) Then, Catalog.pm and genbki.pl are
taught to collect this information into a table in a new generated
header "system_fk_info.h". The only user of that at the moment is
a new SQL function pg_get_catalog_foreign_keys(), which exposes the
table to SQL. The oidjoins regression test is rewritten to use
pg_get_catalog_foreign_keys() to find out which columns to check.
Aside from removing the need for manual maintenance of that test
script, this allows it to cover numerous relationships that were not
checked by the old implementation based on findoidjoins. (As of this
commit, 217 relationships are checked by the test, versus 181 before.)
Discussion: https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us
2021-02-02 23:11:55 +01:00
|
|
|
/* OID of entry in pg_type for underlying composite type, if any */
|
|
|
|
|
Oid reloftype BKI_DEFAULT(0) BKI_LOOKUP_OPT(pg_type);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
|
/* class owner */
|
2021-02-03 18:01:48 +01:00
|
|
|
Oid relowner BKI_DEFAULT(POSTGRES) BKI_LOOKUP(pg_authid);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
2022-09-28 15:45:27 +02:00
|
|
|
/* access method; 0 if not a table / index */
|
|
|
|
|
Oid relam BKI_DEFAULT(heap) BKI_LOOKUP_OPT(pg_am);
|
|
|
|
|
|
|
|
|
|
/* identifier of physical storage file */
|
|
|
|
|
/* relfilenode == 0 means it is a "mapped" relation, see relmapper.c */
|
|
|
|
|
Oid relfilenode BKI_DEFAULT(0);
|
|
|
|
|
|
2019-03-12 17:30:35 +01:00
|
|
|
/* identifier of table space for relation (0 means default for database) */
|
Build in some knowledge about foreign-key relationships in the catalogs.
This follows in the spirit of commit dfb75e478, which created primary
key and uniqueness constraints to improve the visibility of constraints
imposed on the system catalogs. While our catalogs contain many
foreign-key-like relationships, they don't quite follow SQL semantics,
in that the convention for an omitted reference is to write zero not
NULL. Plus, we have some cases in which there are arrays each of whose
elements is supposed to be an FK reference; SQL has no way to model that.
So we can't create actual foreign key constraints to describe the
situation. Nonetheless, we can collect and use knowledge about these
relationships.
This patch therefore adds annotations to the catalog header files to
declare foreign-key relationships. (The BKI_LOOKUP annotations cover
simple cases, but we weren't previously distinguishing which such
columns are allowed to contain zeroes; we also need new markings for
multi-column FK references.) Then, Catalog.pm and genbki.pl are
taught to collect this information into a table in a new generated
header "system_fk_info.h". The only user of that at the moment is
a new SQL function pg_get_catalog_foreign_keys(), which exposes the
table to SQL. The oidjoins regression test is rewritten to use
pg_get_catalog_foreign_keys() to find out which columns to check.
Aside from removing the need for manual maintenance of that test
script, this allows it to cover numerous relationships that were not
checked by the old implementation based on findoidjoins. (As of this
commit, 217 relationships are checked by the test, versus 181 before.)
Discussion: https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us
2021-02-02 23:11:55 +01:00
|
|
|
Oid reltablespace BKI_DEFAULT(0) BKI_LOOKUP_OPT(pg_tablespace);
|
2019-03-12 17:30:35 +01:00
|
|
|
|
|
|
|
|
/* # 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
|
|
|
|
Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.
Historically, we've considered the state with relpages and reltuples
both zero as indicating that we do not know the table's tuple density.
This is problematic because it's impossible to distinguish "never yet
vacuumed" from "vacuumed and seen to be empty". In particular, a user
cannot use VACUUM or ANALYZE to override the planner's normal heuristic
that an empty table should not be believed to be empty because it is
probably about to get populated. That heuristic is a good safety
measure, so I don't care to abandon it, but there should be a way to
override it if the table is indeed intended to stay empty.
Hence, represent the initial state of ignorance by setting reltuples
to -1 (relpages is still set to zero), and apply the minimum-ten-pages
heuristic only when reltuples is still -1. If the table is empty,
VACUUM or ANALYZE (but not CREATE INDEX) will override that to
reltuples = relpages = 0, and then we'll plan on that basis.
This requires a bunch of fiddly little changes, but we can get rid of
some ugly kluges that were formerly needed to maintain the old definition.
One notable point is that FDWs' GetForeignRelSize methods will see
baserel->tuples = -1 when no ANALYZE has been done on the foreign table.
That seems like a net improvement, since those methods were formerly
also in the dark about what baserel->tuples = 0 really meant. Still,
it is an API change.
I bumped catversion because code predating this change would get confused
by seeing reltuples = -1.
Discussion: https://postgr.es/m/F02298E0-6EF4-49A1-BCB6-C484794D9ACC@thebuild.com
2020-08-30 18:21:51 +02:00
|
|
|
/* # of tuples (not always up-to-date; -1 means "unknown") */
|
|
|
|
|
float4 reltuples BKI_DEFAULT(-1);
|
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 */
|
Build in some knowledge about foreign-key relationships in the catalogs.
This follows in the spirit of commit dfb75e478, which created primary
key and uniqueness constraints to improve the visibility of constraints
imposed on the system catalogs. While our catalogs contain many
foreign-key-like relationships, they don't quite follow SQL semantics,
in that the convention for an omitted reference is to write zero not
NULL. Plus, we have some cases in which there are arrays each of whose
elements is supposed to be an FK reference; SQL has no way to model that.
So we can't create actual foreign key constraints to describe the
situation. Nonetheless, we can collect and use knowledge about these
relationships.
This patch therefore adds annotations to the catalog header files to
declare foreign-key relationships. (The BKI_LOOKUP annotations cover
simple cases, but we weren't previously distinguishing which such
columns are allowed to contain zeroes; we also need new markings for
multi-column FK references.) Then, Catalog.pm and genbki.pl are
taught to collect this information into a table in a new generated
header "system_fk_info.h". The only user of that at the moment is
a new SQL function pg_get_catalog_foreign_keys(), which exposes the
table to SQL. The oidjoins regression test is rewritten to use
pg_get_catalog_foreign_keys() to find out which columns to check.
Aside from removing the need for manual maintenance of that test
script, this allows it to cover numerous relationships that were not
checked by the old implementation based on findoidjoins. (As of this
commit, 217 relationships are checked by the test, versus 181 before.)
Discussion: https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us
2021-02-02 23:11:55 +01:00
|
|
|
Oid reltoastrelid BKI_DEFAULT(0) BKI_LOOKUP_OPT(pg_class);
|
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
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*
|
2001-08-10 20:57:42 +02:00
|
|
|
* Class pg_attribute must contain exactly "relnatts" user attributes
|
|
|
|
|
* (with attnums ranging from 1 to relnatts) for this class. It may also
|
|
|
|
|
* contain entries with negative attnums for system attributes.
|
1996-08-28 03:59:28 +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
|
|
|
|
Build in some knowledge about foreign-key relationships in the catalogs.
This follows in the spirit of commit dfb75e478, which created primary
key and uniqueness constraints to improve the visibility of constraints
imposed on the system catalogs. While our catalogs contain many
foreign-key-like relationships, they don't quite follow SQL semantics,
in that the convention for an omitted reference is to write zero not
NULL. Plus, we have some cases in which there are arrays each of whose
elements is supposed to be an FK reference; SQL has no way to model that.
So we can't create actual foreign key constraints to describe the
situation. Nonetheless, we can collect and use knowledge about these
relationships.
This patch therefore adds annotations to the catalog header files to
declare foreign-key relationships. (The BKI_LOOKUP annotations cover
simple cases, but we weren't previously distinguishing which such
columns are allowed to contain zeroes; we also need new markings for
multi-column FK references.) Then, Catalog.pm and genbki.pl are
taught to collect this information into a table in a new generated
header "system_fk_info.h". The only user of that at the moment is
a new SQL function pg_get_catalog_foreign_keys(), which exposes the
table to SQL. The oidjoins regression test is rewritten to use
pg_get_catalog_foreign_keys() to find out which columns to check.
Aside from removing the need for manual maintenance of that test
script, this allows it to cover numerous relationships that were not
checked by the old implementation based on findoidjoins. (As of this
commit, 217 relationships are checked by the test, versus 181 before.)
Discussion: https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us
2021-02-02 23:11:55 +01:00
|
|
|
/* link to original rel during table rewrite; otherwise 0 */
|
|
|
|
|
Oid relrewrite BKI_DEFAULT(0) BKI_LOOKUP_OPT(pg_class);
|
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
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
|
* Form_pg_class corresponds to a pointer to a tuple with
|
|
|
|
|
* the format of pg_class relation.
|
|
|
|
|
* ----------------
|
|
|
|
|
*/
|
|
|
|
|
typedef FormData_pg_class *Form_pg_class;
|
|
|
|
|
|
2023-08-31 08:14:57 +02:00
|
|
|
DECLARE_UNIQUE_INDEX_PKEY(pg_class_oid_index, 2662, ClassOidIndexId, pg_class, btree(oid oid_ops));
|
|
|
|
|
DECLARE_UNIQUE_INDEX(pg_class_relname_nsp_index, 2663, ClassNameNspIndexId, pg_class, btree(relname name_ops, relnamespace oid_ops));
|
|
|
|
|
DECLARE_INDEX(pg_class_tblspc_relfilenode_index, 3455, ClassTblspcRelfilenodeIndexId, pg_class, btree(reltablespace oid_ops, relfilenode oid_ops));
|
2020-11-07 12:11:40 +01:00
|
|
|
|
2024-01-23 07:13:38 +01:00
|
|
|
MAKE_SYSCACHE(RELOID, pg_class_oid_index, 128);
|
|
|
|
|
MAKE_SYSCACHE(RELNAMENSP, pg_class_relname_nsp_index, 128);
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
#define RELKIND_RELATION 'r' /* ordinary table */
|
1996-08-28 03:59:28 +02:00
|
|
|
#define RELKIND_INDEX 'i' /* secondary index */
|
2011-02-23 01:23:23 +01:00
|
|
|
#define RELKIND_SEQUENCE 'S' /* sequence object */
|
|
|
|
|
#define RELKIND_TOASTVALUE 't' /* for out-of-line values */
|
2000-10-16 18:19:14 +02:00
|
|
|
#define RELKIND_VIEW 'v' /* view */
|
2017-03-10 19:15:47 +01:00
|
|
|
#define RELKIND_MATVIEW 'm' /* materialized view */
|
2002-08-15 18:36:08 +02:00
|
|
|
#define RELKIND_COMPOSITE_TYPE 'c' /* composite type */
|
2011-01-02 05:48:11 +01:00
|
|
|
#define RELKIND_FOREIGN_TABLE 'f' /* foreign table */
|
2017-03-10 19:15:47 +01:00
|
|
|
#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
|
|
|
|
2011-02-23 01:23:23 +01: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
|
2021-12-22 08:37:58 +01:00
|
|
|
* has the same meaning as 'n'.
|
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)
|
|
|
|
|
|
2021-12-03 13:38:26 +01:00
|
|
|
#define RELKIND_HAS_PARTITIONS(relkind) \
|
|
|
|
|
((relkind) == RELKIND_PARTITIONED_TABLE || \
|
|
|
|
|
(relkind) == RELKIND_PARTITIONED_INDEX)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Relation kinds that support tablespaces: All relation kinds with storage
|
|
|
|
|
* support tablespaces, except that we don't support moving sequences around
|
|
|
|
|
* into different tablespaces. Partitioned tables and indexes don't have
|
|
|
|
|
* physical storage, but they have a tablespace settings so that their
|
|
|
|
|
* children can inherit it.
|
|
|
|
|
*/
|
|
|
|
|
#define RELKIND_HAS_TABLESPACE(relkind) \
|
|
|
|
|
((RELKIND_HAS_STORAGE(relkind) || RELKIND_HAS_PARTITIONS(relkind)) \
|
|
|
|
|
&& (relkind) != RELKIND_SEQUENCE)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Relation kinds with a table access method (rd_tableam). Although sequences
|
|
|
|
|
* use the heap table AM, they are enough of a special case in most uses that
|
2024-03-25 16:30:36 +01:00
|
|
|
* they are not included here. Likewise, partitioned tables can have an access
|
|
|
|
|
* method defined so that their partitions can inherit it, but they do not set
|
|
|
|
|
* rd_tableam; hence, this is handled specially outside of this macro.
|
2021-12-03 13:38:26 +01:00
|
|
|
*/
|
|
|
|
|
#define RELKIND_HAS_TABLE_AM(relkind) \
|
|
|
|
|
((relkind) == RELKIND_RELATION || \
|
|
|
|
|
(relkind) == RELKIND_TOASTVALUE || \
|
|
|
|
|
(relkind) == RELKIND_MATVIEW)
|
|
|
|
|
|
Improve error messages about mismatching relkind
Most error messages about a relkind that was not supported or
appropriate for the command was of the pattern
"relation \"%s\" is not a table, foreign table, or materialized view"
This style can become verbose and tedious to maintain. Moreover, it's
not very helpful: If I'm trying to create a comment on a TOAST table,
which is not supported, then the information that I could have created
a comment on a materialized view is pointless.
Instead, write the primary error message shorter and saying more
directly that what was attempted is not possible. Then, in the detail
message, explain that the operation is not supported for the relkind
the object was. To simplify that, add a new function
errdetail_relkind_not_supported() that does this.
In passing, make use of RELKIND_HAS_STORAGE() where appropriate,
instead of listing out the relkinds individually.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://www.postgresql.org/message-id/flat/dc35a398-37d0-75ce-07ea-1dd71d98f8ec@2ndquadrant.com
2021-07-08 09:38:52 +02:00
|
|
|
extern int errdetail_relkind_not_supported(char relkind);
|
2018-12-17 19:37:40 +01: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
|
|
|
#endif /* EXPOSE_TO_CLIENT_CODE */
|
|
|
|
|
|
2000-06-17 06:56:39 +02:00
|
|
|
#endif /* PG_CLASS_H */
|
