2002-07-12 20:43:19 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_constraint.h
|
2018-04-19 23:14:09 +02:00
|
|
|
* definition of the "constraint" system catalog (pg_constraint)
|
2002-07-12 20:43:19 +02:00
|
|
|
*
|
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2002-07-12 20:43:19 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/pg_constraint.h
|
2002-07-12 20:43:19 +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.
|
2002-07-12 20:43:19 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef PG_CONSTRAINT_H
|
|
|
|
#define PG_CONSTRAINT_H
|
|
|
|
|
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_constraint_d.h"
|
2006-06-29 00:11:01 +02:00
|
|
|
|
2018-04-08 20:35:29 +02:00
|
|
|
#include "catalog/dependency.h"
|
|
|
|
#include "nodes/pg_list.h"
|
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
/* ----------------
|
|
|
|
* pg_constraint definition. cpp turns this into
|
|
|
|
* typedef struct FormData_pg_constraint
|
|
|
|
* ----------------
|
|
|
|
*/
|
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_constraint,2606,ConstraintRelationId)
|
2002-07-12 20:43:19 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* conname + connamespace is deliberately not unique; we allow, for
|
|
|
|
* example, the same name to be used for constraints of different
|
|
|
|
* relations. This is partly for backwards compatibility with past
|
2005-10-15 04:49:52 +02:00
|
|
|
* Postgres practice, and partly because we don't want to have to obtain a
|
|
|
|
* global lock to generate a globally unique name for a nameless
|
2014-05-06 18:12:18 +02:00
|
|
|
* constraint. We associate a namespace with constraint names only for
|
2010-01-17 23:56:23 +01:00
|
|
|
* SQL-spec compatibility.
|
2002-07-12 20:43:19 +02:00
|
|
|
*/
|
|
|
|
NameData conname; /* name of this constraint */
|
|
|
|
Oid connamespace; /* OID of namespace containing constraint */
|
|
|
|
char contype; /* constraint type; see codes below */
|
|
|
|
bool condeferrable; /* deferrable constraint? */
|
|
|
|
bool condeferred; /* deferred by default? */
|
2011-02-08 13:23:20 +01:00
|
|
|
bool convalidated; /* constraint has been validated? */
|
2002-07-12 20:43:19 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* conrelid and conkey are only meaningful if the constraint applies to a
|
|
|
|
* specific relation (this excludes domain constraints and assertions).
|
|
|
|
* Otherwise conrelid is 0 and conkey is NULL.
|
2002-07-12 20:43:19 +02:00
|
|
|
*/
|
|
|
|
Oid conrelid; /* relation this constraint constrains */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* contypid links to the pg_type row for a domain if this is a domain
|
2014-05-06 18:12:18 +02:00
|
|
|
* constraint. Otherwise it's 0.
|
2002-07-12 20:43:19 +02:00
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* For SQL-style global ASSERTIONs, both conrelid and contypid would be
|
|
|
|
* zero. This is not presently supported, however.
|
2002-07-12 20:43:19 +02:00
|
|
|
*/
|
|
|
|
Oid contypid; /* domain this constraint constrains */
|
|
|
|
|
2009-07-28 04:56:31 +02:00
|
|
|
/*
|
|
|
|
* conindid links to the index supporting the constraint, if any;
|
2010-03-11 04:36:22 +01:00
|
|
|
* otherwise it's 0. This is used for unique, primary-key, and exclusion
|
|
|
|
* constraints, and less obviously for foreign-key constraints (where the
|
|
|
|
* index is a unique index on the referenced relation's referenced
|
|
|
|
* columns). Notice that the index is on conrelid in the first case but
|
|
|
|
* confrelid in the second.
|
2009-07-28 04:56:31 +02:00
|
|
|
*/
|
|
|
|
Oid conindid; /* index supporting this constraint */
|
|
|
|
|
2018-03-23 14:48:22 +01:00
|
|
|
/*
|
|
|
|
* If this constraint is on a partition inherited from a partitioned
|
|
|
|
* table, this is the OID of the corresponding constraint in the parent.
|
|
|
|
*/
|
|
|
|
Oid conparentid;
|
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
/*
|
|
|
|
* These fields, plus confkey, are only meaningful for a foreign-key
|
2014-05-06 18:12:18 +02:00
|
|
|
* constraint. Otherwise confrelid is 0 and the char fields are spaces.
|
2002-07-12 20:43:19 +02:00
|
|
|
*/
|
|
|
|
Oid confrelid; /* relation referenced by foreign key */
|
|
|
|
char confupdtype; /* foreign key's ON UPDATE action */
|
|
|
|
char confdeltype; /* foreign key's ON DELETE action */
|
|
|
|
char confmatchtype; /* foreign key's match type */
|
|
|
|
|
2008-05-10 01:32:05 +02:00
|
|
|
/* Has a local definition (hence, do not drop when coninhcount is 0) */
|
|
|
|
bool conislocal;
|
|
|
|
|
|
|
|
/* Number of times inherited from direct parent relation(s) */
|
2012-06-25 00:51:46 +02:00
|
|
|
int32 coninhcount;
|
2008-05-10 01:32:05 +02:00
|
|
|
|
2011-12-05 19:10:18 +01:00
|
|
|
/* Has a local definition and cannot be inherited */
|
2012-04-21 04:46:20 +02:00
|
|
|
bool connoinherit;
|
2011-12-05 19:10:18 +01:00
|
|
|
|
2012-01-27 19:16:17 +01:00
|
|
|
#ifdef CATALOG_VARLEN /* variable-length fields start here */
|
2012-06-10 21:20:04 +02:00
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Columns of conrelid that the constraint applies to, if known (this is
|
|
|
|
* NULL for trigger constraints)
|
2002-07-12 20:43:19 +02:00
|
|
|
*/
|
2012-06-25 00:51:46 +02:00
|
|
|
int16 conkey[1];
|
2002-07-12 20:43:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If a foreign key, the referenced columns of confrelid
|
|
|
|
*/
|
2012-06-25 00:51:46 +02:00
|
|
|
int16 confkey[1];
|
2002-07-12 20:43:19 +02:00
|
|
|
|
2007-02-14 02:58:58 +01:00
|
|
|
/*
|
|
|
|
* If a foreign key, the OIDs of the PK = FK equality operators for each
|
|
|
|
* column of the constraint
|
|
|
|
*/
|
|
|
|
Oid conpfeqop[1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If a foreign key, the OIDs of the PK = PK equality operators for each
|
|
|
|
* column of the constraint (i.e., equality for the referenced columns)
|
|
|
|
*/
|
|
|
|
Oid conppeqop[1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If a foreign key, the OIDs of the FK = FK equality operators for each
|
|
|
|
* column of the constraint (i.e., equality for the referencing columns)
|
|
|
|
*/
|
|
|
|
Oid conffeqop[1];
|
|
|
|
|
2009-12-07 06:22:23 +01:00
|
|
|
/*
|
|
|
|
* If an exclusion constraint, the OIDs of the exclusion operators for
|
|
|
|
* each column of the constraint
|
|
|
|
*/
|
|
|
|
Oid conexclop[1];
|
|
|
|
|
2002-07-12 20:43:19 +02:00
|
|
|
/*
|
|
|
|
* If a check constraint, nodeToString representation of expression
|
|
|
|
*/
|
2010-09-03 03:34:55 +02:00
|
|
|
pg_node_tree conbin;
|
2002-07-12 20:43:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If a check constraint, source-text representation of expression
|
|
|
|
*/
|
|
|
|
text consrc;
|
2012-01-27 19:16:17 +01:00
|
|
|
#endif
|
2002-07-12 20:43:19 +02:00
|
|
|
} FormData_pg_constraint;
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* Form_pg_constraint corresponds to a pointer to a tuple with
|
|
|
|
* the format of pg_constraint relation.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
typedef FormData_pg_constraint *Form_pg_constraint;
|
|
|
|
|
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
|
2002-07-12 20:43:19 +02:00
|
|
|
|
|
|
|
/* Valid values for contype */
|
|
|
|
#define CONSTRAINT_CHECK 'c'
|
|
|
|
#define CONSTRAINT_FOREIGN 'f'
|
|
|
|
#define CONSTRAINT_PRIMARY 'p'
|
|
|
|
#define CONSTRAINT_UNIQUE 'u'
|
2010-01-17 23:56:23 +01:00
|
|
|
#define CONSTRAINT_TRIGGER 't'
|
2009-12-07 06:22:23 +01:00
|
|
|
#define CONSTRAINT_EXCLUSION 'x'
|
2002-07-12 20:43:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Valid values for confupdtype and confdeltype are the FKCONSTR_ACTION_xxx
|
|
|
|
* constants defined in parsenodes.h. Valid values for confmatchtype are
|
|
|
|
* the FKCONSTR_MATCH_xxx constants defined in parsenodes.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
|
|
|
#endif /* EXPOSE_TO_CLIENT_CODE */
|
|
|
|
|
2018-04-08 20:35:29 +02:00
|
|
|
/*
|
|
|
|
* Identify constraint type for lookup purposes
|
|
|
|
*/
|
|
|
|
typedef enum ConstraintCategory
|
|
|
|
{
|
|
|
|
CONSTRAINT_RELATION,
|
|
|
|
CONSTRAINT_DOMAIN,
|
|
|
|
CONSTRAINT_ASSERTION /* for future expansion */
|
|
|
|
} ConstraintCategory;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Used when cloning a foreign key constraint to a partition, so that the
|
|
|
|
* caller can optionally set up a verification pass for it.
|
|
|
|
*/
|
|
|
|
typedef struct ClonedConstraint
|
|
|
|
{
|
|
|
|
Oid relid;
|
|
|
|
Oid refrelid;
|
|
|
|
Oid conindid;
|
|
|
|
Oid conid;
|
|
|
|
Constraint *constraint;
|
|
|
|
} ClonedConstraint;
|
|
|
|
|
|
|
|
|
|
|
|
extern Oid CreateConstraintEntry(const char *constraintName,
|
|
|
|
Oid constraintNamespace,
|
|
|
|
char constraintType,
|
|
|
|
bool isDeferrable,
|
|
|
|
bool isDeferred,
|
|
|
|
bool isValidated,
|
|
|
|
Oid parentConstrId,
|
|
|
|
Oid relId,
|
|
|
|
const int16 *constraintKey,
|
|
|
|
int constraintNKeys,
|
|
|
|
int constraintNTotalKeys,
|
|
|
|
Oid domainId,
|
|
|
|
Oid indexRelId,
|
|
|
|
Oid foreignRelId,
|
|
|
|
const int16 *foreignKey,
|
|
|
|
const Oid *pfEqOp,
|
|
|
|
const Oid *ppEqOp,
|
|
|
|
const Oid *ffEqOp,
|
|
|
|
int foreignNKeys,
|
|
|
|
char foreignUpdateType,
|
|
|
|
char foreignDeleteType,
|
|
|
|
char foreignMatchType,
|
|
|
|
const Oid *exclOp,
|
|
|
|
Node *conExpr,
|
|
|
|
const char *conBin,
|
|
|
|
const char *conSrc,
|
|
|
|
bool conIsLocal,
|
|
|
|
int conInhCount,
|
|
|
|
bool conNoInherit,
|
|
|
|
bool is_internal);
|
|
|
|
|
|
|
|
extern void CloneForeignKeyConstraints(Oid parentId, Oid relationId,
|
|
|
|
List **cloned);
|
|
|
|
|
|
|
|
extern void RemoveConstraintById(Oid conId);
|
|
|
|
extern void RenameConstraintById(Oid conId, const char *newname);
|
|
|
|
|
|
|
|
extern bool ConstraintNameIsUsed(ConstraintCategory conCat, Oid objId,
|
|
|
|
Oid objNamespace, const char *conname);
|
|
|
|
extern char *ChooseConstraintName(const char *name1, const char *name2,
|
|
|
|
const char *label, Oid namespaceid,
|
|
|
|
List *others);
|
|
|
|
|
|
|
|
extern void AlterConstraintNamespaces(Oid ownerId, Oid oldNspId,
|
|
|
|
Oid newNspId, bool isType, ObjectAddresses *objsMoved);
|
|
|
|
extern void ConstraintSetParentConstraint(Oid childConstrId,
|
|
|
|
Oid parentConstrId);
|
|
|
|
extern Oid get_relation_constraint_oid(Oid relid, const char *conname, bool missing_ok);
|
|
|
|
extern Bitmapset *get_relation_constraint_attnos(Oid relid, const char *conname,
|
|
|
|
bool missing_ok, Oid *constraintOid);
|
|
|
|
extern Oid get_domain_constraint_oid(Oid typid, const char *conname, bool missing_ok);
|
|
|
|
extern Oid get_relation_idx_constraint_oid(Oid relationId, Oid indexId);
|
|
|
|
|
|
|
|
extern Bitmapset *get_primary_key_attnos(Oid relid, bool deferrableOk,
|
|
|
|
Oid *constraintOid);
|
|
|
|
|
|
|
|
extern bool check_functional_grouping(Oid relid,
|
|
|
|
Index varno, Index varlevelsup,
|
|
|
|
List *grouping_columns,
|
|
|
|
List **constraintDeps);
|
|
|
|
|
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_CONSTRAINT_H */
|