1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* rel.h
|
2000-01-31 05:35:57 +01:00
|
|
|
* POSTGRES relation descriptor (a/k/a relcache entry) definitions.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, 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/utils/rel.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef REL_H
|
1996-08-28 03:59:28 +02:00
|
|
|
#define REL_H
|
|
|
|
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "access/tupdesc.h"
|
2016-04-08 21:36:30 +02:00
|
|
|
#include "access/xlog.h"
|
1999-07-16 19:07:40 +02:00
|
|
|
#include "catalog/pg_class.h"
|
2002-02-19 21:11:20 +01:00
|
|
|
#include "catalog/pg_index.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
#include "catalog/pg_publication.h"
|
2005-05-28 01:31:21 +02:00
|
|
|
#include "fmgr.h"
|
2007-09-20 19:56:33 +02:00
|
|
|
#include "nodes/bitmapset.h"
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "rewrite/prs2lock.h"
|
2001-06-28 01:31:40 +02:00
|
|
|
#include "storage/block.h"
|
|
|
|
#include "storage/relfilenode.h"
|
2008-06-19 02:46:06 +02:00
|
|
|
#include "utils/relcache.h"
|
2011-02-23 18:18:09 +01:00
|
|
|
#include "utils/reltrigger.h"
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-01-31 05:35:57 +01:00
|
|
|
|
1999-09-18 21:08:25 +02:00
|
|
|
/*
|
|
|
|
* LockRelId and LockInfo really belong to lmgr.h, but it's more convenient
|
|
|
|
* to declare them here so we can have a LockInfoData field in a Relation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
typedef struct LockRelId
|
|
|
|
{
|
|
|
|
Oid relId; /* a relation identifier */
|
|
|
|
Oid dbId; /* a database identifier */
|
|
|
|
} LockRelId;
|
|
|
|
|
|
|
|
typedef struct LockInfoData
|
|
|
|
{
|
|
|
|
LockRelId lockRelId;
|
|
|
|
} LockInfoData;
|
|
|
|
|
|
|
|
typedef LockInfoData *LockInfo;
|
|
|
|
|
2000-01-31 05:35:57 +01:00
|
|
|
/*
|
|
|
|
* Here are the contents of a relation cache entry.
|
|
|
|
*/
|
1999-09-18 21:08:25 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct RelationData
|
|
|
|
{
|
2004-02-10 02:55:27 +01:00
|
|
|
RelFileNode rd_node; /* relation physical identifier */
|
|
|
|
/* use "struct" here to avoid needing to include smgr.h: */
|
2004-08-29 07:07:03 +02:00
|
|
|
struct SMgrRelationData *rd_smgr; /* cached file handle, or NULL */
|
2001-06-28 01:31:40 +02:00
|
|
|
int rd_refcnt; /* reference count */
|
2010-08-13 22:10:54 +02:00
|
|
|
BackendId rd_backend; /* owning backend id, if temporary relation */
|
2012-12-18 02:15:32 +01:00
|
|
|
bool rd_islocaltemp; /* rel is a temp rel of this session */
|
2004-08-28 22:31:44 +02:00
|
|
|
bool rd_isnailed; /* rel is nailed in cache */
|
|
|
|
bool rd_isvalid; /* relcache entry is valid */
|
2005-10-15 04:49:52 +02:00
|
|
|
char rd_indexvalid; /* state of rd_indexlist: 0 = not valid, 1 =
|
|
|
|
* valid, 2 = temporarily forced */
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
bool rd_statvalid; /* is rd_statlist valid? */
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-08-28 22:31:44 +02:00
|
|
|
/*
|
2004-09-16 18:58:44 +02:00
|
|
|
* rd_createSubid is the ID of the highest subtransaction the rel has
|
2005-10-15 04:49:52 +02:00
|
|
|
* survived into; or zero if the rel was not created in the current top
|
2013-05-29 22:58:43 +02:00
|
|
|
* transaction. This can be now be relied on, whereas previously it could
|
|
|
|
* be "forgotten" in earlier releases. Likewise, rd_newRelfilenodeSubid is
|
|
|
|
* the ID of the highest subtransaction the relfilenode change has
|
|
|
|
* survived into, or zero if not changed in the current transaction (or we
|
|
|
|
* have forgotten changing it). rd_newRelfilenodeSubid can be forgotten
|
|
|
|
* when a relation has multiple new relfilenodes within a single
|
2015-05-20 18:44:46 +02:00
|
|
|
* transaction, with one of them occurring in a subsequently aborted
|
2013-05-29 22:58:43 +02:00
|
|
|
* subtransaction, e.g. BEGIN; TRUNCATE t; SAVEPOINT save; TRUNCATE t;
|
|
|
|
* ROLLBACK TO save; -- rd_newRelfilenode is now forgotten
|
2004-08-28 22:31:44 +02:00
|
|
|
*/
|
2010-01-10 23:19:17 +01:00
|
|
|
SubTransactionId rd_createSubid; /* rel was created in current xact */
|
|
|
|
SubTransactionId rd_newRelfilenodeSubid; /* new relfilenode assigned in
|
|
|
|
* current xact */
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
Form_pg_class rd_rel; /* RELATION tuple */
|
2002-02-19 21:11:20 +01:00
|
|
|
TupleDesc rd_att; /* tuple descriptor */
|
1999-09-18 21:08:25 +02:00
|
|
|
Oid rd_id; /* relation's object id */
|
2000-06-17 23:49:04 +02:00
|
|
|
LockInfoData rd_lockInfo; /* lock mgr's info for locking relation */
|
1997-09-08 04:41:22 +02:00
|
|
|
RuleLock *rd_rules; /* rewrite rules */
|
2000-06-30 09:04:23 +02:00
|
|
|
MemoryContext rd_rulescxt; /* private memory cxt for rd_rules, if any */
|
2000-01-31 05:35:57 +01:00
|
|
|
TriggerDesc *trigdesc; /* Trigger info, or NULL if rel has none */
|
Clean up includes from RLS patch
The initial patch for RLS mistakenly included headers associated with
the executor and planner bits in rewrite/rowsecurity.h. Per policy and
general good sense, executor headers should not be included in planner
headers or vice versa.
The include of execnodes.h was a mistaken holdover from previous
versions, while the include of relation.h was used for Relation's
definition, which should have been coming from utils/relcache.h. This
patch cleans these issues up, adds comments to the RowSecurityPolicy
struct and the RowSecurityConfigType enum, and changes Relation->rsdesc
to Relation->rd_rsdesc to follow Relation field naming convention.
Additionally, utils/rel.h was including rewrite/rowsecurity.h, which
wasn't a great idea since that was pulling in things not really needed
in utils/rel.h (which gets included in quite a few places). Instead,
use 'struct RowSecurityDesc' for the rd_rsdesc field and add comments
explaining why.
Lastly, add an include into access/nbtree/nbtsort.c for
utils/sortsupport.h, which was evidently missed due to the above mess.
Pointed out by Tom in 16970.1415838651@sss.pgh.pa.us; note that the
concerns regarding a similar situation in the custom-path commit still
need to be addressed.
2014-11-14 22:53:51 +01:00
|
|
|
/* use "struct" here to avoid needing to include rowsecurity.h: */
|
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
|
|
|
struct RowSecurityDesc *rd_rsdesc; /* row security policies, or NULL */
|
2001-06-22 21:16:24 +02:00
|
|
|
|
2016-06-18 21:22:34 +02:00
|
|
|
/* data managed by RelationGetFKeyList: */
|
|
|
|
List *rd_fkeylist; /* list of ForeignKeyCacheInfo (see below) */
|
|
|
|
bool rd_fkeyvalid; /* true if list has been computed */
|
|
|
|
|
2017-01-24 16:20:02 +01:00
|
|
|
MemoryContext rd_partkeycxt; /* private memory cxt for the below */
|
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
|
|
|
struct PartitionKeyData *rd_partkey; /* partition key, or NULL */
|
2017-01-24 16:20:02 +01:00
|
|
|
MemoryContext rd_pdcxt; /* private context for partdesc */
|
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
|
|
|
struct PartitionDescData *rd_partdesc; /* partitions, or NULL */
|
2017-01-24 16:20:02 +01:00
|
|
|
List *rd_partcheck; /* partition CHECK quals */
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
|
2014-05-14 20:55:48 +02:00
|
|
|
/* data managed by RelationGetIndexList: */
|
|
|
|
List *rd_indexlist; /* list of OIDs of indexes on relation */
|
2017-01-19 18:00:00 +01:00
|
|
|
Oid rd_pkindex; /* OID of primary key, if any */
|
2014-05-14 20:55:48 +02:00
|
|
|
Oid rd_replidindex; /* OID of replica identity index, if any */
|
|
|
|
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
/* data managed by RelationGetStatExtList: */
|
|
|
|
List *rd_statlist; /* list of OIDs of extended stats */
|
|
|
|
|
2014-05-14 20:55:48 +02:00
|
|
|
/* data managed by RelationGetIndexAttrBitmap: */
|
2019-01-15 18:07:10 +01:00
|
|
|
Bitmapset *rd_indexattr; /* identifies columns used in indexes */
|
2014-05-14 20:55:48 +02:00
|
|
|
Bitmapset *rd_keyattr; /* cols that can be ref'd by foreign keys */
|
2017-01-19 18:00:00 +01:00
|
|
|
Bitmapset *rd_pkattr; /* cols included in primary key */
|
2014-05-14 20:55:48 +02:00
|
|
|
Bitmapset *rd_idattr; /* included in replica identity index */
|
2013-11-08 18:30:43 +01:00
|
|
|
|
2017-05-17 22:31:56 +02:00
|
|
|
PublicationActions *rd_pubactions; /* publication actions */
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
/*
|
|
|
|
* rd_options is set whenever rd_rel is loaded into the relcache entry.
|
2006-10-04 02:30:14 +02:00
|
|
|
* Note that you can NOT look into rd_rel for this data. NULL means "use
|
|
|
|
* defaults".
|
2006-07-04 00:45:41 +02:00
|
|
|
*/
|
|
|
|
bytea *rd_options; /* parsed pg_class.reloptions */
|
|
|
|
|
2002-02-19 21:11:20 +01:00
|
|
|
/* These are non-NULL only for an index relation: */
|
|
|
|
Form_pg_index rd_index; /* pg_index tuple describing this index */
|
2010-01-10 23:19:17 +01:00
|
|
|
/* use "struct" here to avoid needing to include htup.h: */
|
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
|
|
|
struct HeapTupleData *rd_indextuple; /* all of pg_index tuple */
|
2002-02-19 21:11:20 +01:00
|
|
|
|
2003-11-09 22:30:38 +01:00
|
|
|
/*
|
|
|
|
* index access support info (used only for an index relation)
|
|
|
|
*
|
2010-11-29 18:29:42 +01:00
|
|
|
* Note: only default support procs for each opclass are cached, namely
|
2011-04-10 17:42:00 +02:00
|
|
|
* those with lefttype and righttype equal to the opclass's opcintype. The
|
|
|
|
* arrays are indexed by support function number, which is a sufficient
|
|
|
|
* identifier given that restriction.
|
2006-04-26 00:46:05 +02:00
|
|
|
*
|
|
|
|
* Note: rd_amcache is available for index AMs to cache private data about
|
|
|
|
* an index. This must be just a cache since it may get reset at any time
|
|
|
|
* (in particular, it will get reset by a relcache inval message for the
|
2014-05-06 18:12:18 +02:00
|
|
|
* index). If used, it must point to a single memory chunk palloc'd in
|
2006-04-26 00:46:05 +02:00
|
|
|
* rd_indexcxt. A relcache reset will include freeing that chunk and
|
|
|
|
* setting rd_amcache = NULL.
|
2003-11-09 22:30:38 +01:00
|
|
|
*/
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
Oid rd_amhandler; /* OID of index AM's handler function */
|
2001-10-07 01:21:45 +02:00
|
|
|
MemoryContext rd_indexcxt; /* private memory cxt for this stuff */
|
Restructure index access method API to hide most of it at the C level.
This patch reduces pg_am to just two columns, a name and a handler
function. All the data formerly obtained from pg_am is now provided
in a C struct returned by the handler function. This is similar to
the designs we've adopted for FDWs and tablesample methods. There
are multiple advantages. For one, the index AM's support functions
are now simple C functions, making them faster to call and much less
error-prone, since the C compiler can now check function signatures.
For another, this will make it far more practical to define index access
methods in installable extensions.
A disadvantage is that SQL-level code can no longer see attributes
of index AMs; in particular, some of the crosschecks in the opr_sanity
regression test are no longer possible from SQL. We've addressed that
by adding a facility for the index AM to perform such checks instead.
(Much more could be done in that line, but for now we're content if the
amvalidate functions more or less replace what opr_sanity used to do.)
We might also want to expose some sort of reporting functionality, but
this patch doesn't do that.
Alexander Korotkov, reviewed by Petr Jelínek, and rather heavily
editorialized on by me.
2016-01-18 01:36:59 +01:00
|
|
|
/* use "struct" here to avoid needing to include amapi.h: */
|
2019-01-22 02:36:55 +01:00
|
|
|
struct IndexAmRoutine *rd_indam; /* index AM's API struct */
|
2006-12-23 01:43:13 +01:00
|
|
|
Oid *rd_opfamily; /* OIDs of op families for each index col */
|
|
|
|
Oid *rd_opcintype; /* OIDs of opclass declared input data types */
|
2001-10-07 01:21:45 +02:00
|
|
|
RegProcedure *rd_support; /* OIDs of support procedures */
|
2005-10-15 04:49:52 +02:00
|
|
|
FmgrInfo *rd_supportinfo; /* lookup info for support procedures */
|
2007-01-09 03:14:16 +01:00
|
|
|
int16 *rd_indoption; /* per-column AM-specific flags */
|
2003-05-28 18:04:02 +02:00
|
|
|
List *rd_indexprs; /* index expression trees, if any */
|
|
|
|
List *rd_indpred; /* index predicate tree, if any */
|
2009-12-07 06:22:23 +01:00
|
|
|
Oid *rd_exclops; /* OIDs of exclusion operators, if any */
|
|
|
|
Oid *rd_exclprocs; /* OIDs of exclusion ops' procs, if any */
|
|
|
|
uint16 *rd_exclstrats; /* exclusion ops' strategy numbers, if any */
|
2006-04-26 00:46:05 +02:00
|
|
|
void *rd_amcache; /* available for use by index AM */
|
2011-04-10 17:42:00 +02:00
|
|
|
Oid *rd_indcollation; /* OIDs of index collations */
|
2001-10-07 01:21:45 +02:00
|
|
|
|
2013-03-07 05:47:38 +01:00
|
|
|
/*
|
|
|
|
* foreign-table support
|
|
|
|
*
|
|
|
|
* rd_fdwroutine must point to a single memory chunk palloc'd in
|
2014-05-06 18:12:18 +02:00
|
|
|
* CacheMemoryContext. It will be freed and reset to NULL on a relcache
|
2013-03-07 05:47:38 +01:00
|
|
|
* reset.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* use "struct" here to avoid needing to include fdwapi.h: */
|
|
|
|
struct FdwRoutine *rd_fdwroutine; /* cached function pointers, or NULL */
|
|
|
|
|
2010-02-04 01:09:14 +01:00
|
|
|
/*
|
|
|
|
* Hack for CLUSTER, rewriting ALTER TABLE, etc: when writing a new
|
|
|
|
* version of a table, we need to make any toast pointers inserted into it
|
|
|
|
* have the existing toast table's OID, not the OID of the transient toast
|
|
|
|
* table. If rd_toastoid isn't InvalidOid, it is the OID to place in
|
|
|
|
* toast pointers inserted into this rel. (Note it's set on the new
|
Fix CLUSTER/VACUUM FULL for toast values owned by recently-updated rows.
In commit 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05, I made CLUSTER and
VACUUM FULL try to preserve toast value OIDs from the original toast table
to the new one. However, if we have to copy both live and recently-dead
versions of a row that has a toasted column, those versions may well
reference the same toast value with the same OID. The patch then led to
duplicate-key failures as we tried to insert the toast value twice with the
same OID. (The previous behavior was not very desirable either, since it
would have silently inserted the same value twice with different OIDs.
That wastes space, but what's worse is that the toast values inserted for
already-dead heap rows would not be reclaimed by subsequent ordinary
VACUUMs, since they go into the new toast table marked live not deleted.)
To fix, check if the copied OID already exists in the new toast table, and
if so, assume that it stores the desired value. This is reasonably safe
since the only case where we will copy an OID from a previous toast pointer
is when toast_insert_or_update was given that toast pointer and so we just
pulled the data from the old table; if we got two different values that way
then we have big problems anyway. We do have to assume that no other
backend is inserting items into the new toast table concurrently, but
that's surely safe for CLUSTER and VACUUM FULL.
Per bug #6393 from Maxim Boguk. Back-patch to 9.0, same as the previous
patch.
2012-01-12 22:40:14 +01:00
|
|
|
* version of the main heap, not the toast table itself.) This also
|
|
|
|
* causes toast_save_datum() to try to preserve toast value OIDs.
|
2010-02-04 01:09:14 +01:00
|
|
|
*/
|
|
|
|
Oid rd_toastoid; /* Real TOAST table's OID, or InvalidOid */
|
|
|
|
|
2007-05-27 05:50:39 +02:00
|
|
|
/* use "struct" here to avoid needing to include pgstat.h: */
|
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
|
|
|
struct PgStat_TableStatus *pgstat_info; /* statistics collection area */
|
1997-09-08 23:56:23 +02:00
|
|
|
} RelationData;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2016-06-18 21:22:34 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ForeignKeyCacheInfo
|
|
|
|
* Information the relcache can cache about foreign key constraints
|
|
|
|
*
|
|
|
|
* This is basically just an image of relevant columns from pg_constraint.
|
|
|
|
* We make it a subclass of Node so that copyObject() can be used on a list
|
|
|
|
* of these, but we also ensure it is a "flat" object without substructure,
|
|
|
|
* so that list_free_deep() is sufficient to free such a list.
|
|
|
|
* The per-FK-column arrays can be fixed-size because we allow at most
|
|
|
|
* INDEX_MAX_KEYS columns in a foreign key constraint.
|
|
|
|
*
|
Correct attach/detach logic for FKs in partitions
There was no code to handle foreign key constraints on partitioned
tables in the case of ALTER TABLE DETACH; and if you happened to ATTACH
a partition that already had an equivalent constraint, that one was
ignored and a new constraint was created. Adding this to the fact that
foreign key cloning reuses the constraint name on the partition instead
of generating a new name (as it probably should, to cater to SQL
standard rules about constraint naming within schemas), the result was a
pretty poor user experience -- the most visible failure was that just
detaching a partition and re-attaching it failed with an error such as
ERROR: duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
DETAIL: Key (conrelid, contypid, conname)=(26702, 0, test_result_asset_id_fkey) already exists.
because it would try to create an identically-named constraint in the
partition. To make matters worse, if you tried to drop the constraint
in the now-independent partition, that would fail because the constraint
was still seen as dependent on the constraint in its former parent
partitioned table:
ERROR: cannot drop inherited constraint "test_result_asset_id_fkey" of relation "test_result_cbsystem_0001_0050_monthly_2018_09"
This fix attacks the problem from two angles: first, when the partition
is detached, the constraint is also marked as independent, so the drop
now works. Second, when the partition is re-attached, we scan existing
constraints searching for one matching the FK in the parent, and if one
exists, we link that one to the parent constraint. So we don't end up
with a duplicate -- and better yet, we don't need to scan the referenced
table to verify that the constraint holds.
To implement this I made a small change to previously planner-only
struct ForeignKeyCacheInfo to contain the constraint OID; also relcache
now maintains the list of FKs for partitioned tables too.
Backpatch to 11.
Reported-by: Michael Vitale (bug #15425)
Discussion: https://postgr.es/m/15425-2dbc9d2aa999f816@postgresql.org
2018-10-12 17:36:26 +02:00
|
|
|
* Currently, we mostly cache fields of interest to the planner, but the set
|
|
|
|
* of fields has already grown the constraint OID for other uses.
|
2016-06-18 21:22:34 +02:00
|
|
|
*/
|
|
|
|
typedef struct ForeignKeyCacheInfo
|
|
|
|
{
|
|
|
|
NodeTag type;
|
Correct attach/detach logic for FKs in partitions
There was no code to handle foreign key constraints on partitioned
tables in the case of ALTER TABLE DETACH; and if you happened to ATTACH
a partition that already had an equivalent constraint, that one was
ignored and a new constraint was created. Adding this to the fact that
foreign key cloning reuses the constraint name on the partition instead
of generating a new name (as it probably should, to cater to SQL
standard rules about constraint naming within schemas), the result was a
pretty poor user experience -- the most visible failure was that just
detaching a partition and re-attaching it failed with an error such as
ERROR: duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
DETAIL: Key (conrelid, contypid, conname)=(26702, 0, test_result_asset_id_fkey) already exists.
because it would try to create an identically-named constraint in the
partition. To make matters worse, if you tried to drop the constraint
in the now-independent partition, that would fail because the constraint
was still seen as dependent on the constraint in its former parent
partitioned table:
ERROR: cannot drop inherited constraint "test_result_asset_id_fkey" of relation "test_result_cbsystem_0001_0050_monthly_2018_09"
This fix attacks the problem from two angles: first, when the partition
is detached, the constraint is also marked as independent, so the drop
now works. Second, when the partition is re-attached, we scan existing
constraints searching for one matching the FK in the parent, and if one
exists, we link that one to the parent constraint. So we don't end up
with a duplicate -- and better yet, we don't need to scan the referenced
table to verify that the constraint holds.
To implement this I made a small change to previously planner-only
struct ForeignKeyCacheInfo to contain the constraint OID; also relcache
now maintains the list of FKs for partitioned tables too.
Backpatch to 11.
Reported-by: Michael Vitale (bug #15425)
Discussion: https://postgr.es/m/15425-2dbc9d2aa999f816@postgresql.org
2018-10-12 17:36:26 +02:00
|
|
|
Oid conoid; /* oid of the constraint itself */
|
2016-06-18 21:22:34 +02:00
|
|
|
Oid conrelid; /* relation constrained by the foreign key */
|
|
|
|
Oid confrelid; /* relation referenced by the foreign key */
|
|
|
|
int nkeys; /* number of columns in the foreign key */
|
|
|
|
/* these arrays each have nkeys valid entries: */
|
|
|
|
AttrNumber conkey[INDEX_MAX_KEYS]; /* cols in referencing table */
|
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
|
|
|
AttrNumber confkey[INDEX_MAX_KEYS]; /* cols in referenced table */
|
|
|
|
Oid conpfeqop[INDEX_MAX_KEYS]; /* PK = FK operator OIDs */
|
2016-06-18 21:22:34 +02:00
|
|
|
} ForeignKeyCacheInfo;
|
|
|
|
|
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
/*
|
|
|
|
* StdRdOptions
|
|
|
|
* Standard contents of rd_options for heaps and generic indexes.
|
|
|
|
*
|
|
|
|
* RelationGetFillFactor() and RelationGetTargetPageFreeSpace() can only
|
|
|
|
* be applied to relations that use this format or a superset for
|
|
|
|
* private options data.
|
|
|
|
*/
|
2009-02-09 21:57:59 +01:00
|
|
|
/* autovacuum-related reloptions. */
|
|
|
|
typedef struct AutoVacOpts
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
bool enabled;
|
|
|
|
int vacuum_threshold;
|
|
|
|
int analyze_threshold;
|
|
|
|
int vacuum_cost_delay;
|
|
|
|
int vacuum_cost_limit;
|
|
|
|
int freeze_min_age;
|
|
|
|
int freeze_max_age;
|
|
|
|
int freeze_table_age;
|
Separate multixact freezing parameters from xid's
Previously we were piggybacking on transaction ID parameters to freeze
multixacts; but since there isn't necessarily any relationship between
rates of Xid and multixact consumption, this turns out not to be a good
idea.
Therefore, we now have multixact-specific freezing parameters:
vacuum_multixact_freeze_min_age: when to remove multis as we come across
them in vacuum (default to 5 million, i.e. early in comparison to Xid's
default of 50 million)
vacuum_multixact_freeze_table_age: when to force whole-table scans
instead of scanning only the pages marked as not all visible in
visibility map (default to 150 million, same as for Xids). Whichever of
both which reaches the 150 million mark earlier will cause a whole-table
scan.
autovacuum_multixact_freeze_max_age: when for cause emergency,
uninterruptible whole-table scans (default to 400 million, double as
that for Xids). This means there shouldn't be more frequent emergency
vacuuming than previously, unless multixacts are being used very
rapidly.
Backpatch to 9.3 where multixacts were made to persist enough to require
freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of
fields in an unnatural place, and StdRdOptions is split in two so that
the newly added fields can go at the end.
Patch by me, reviewed by Robert Haas, with additional input from Andres
Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
|
|
|
int multixact_freeze_min_age;
|
|
|
|
int multixact_freeze_max_age;
|
|
|
|
int multixact_freeze_table_age;
|
2015-04-03 16:55:50 +02:00
|
|
|
int log_min_duration;
|
2009-06-11 16:49:15 +02:00
|
|
|
float8 vacuum_scale_factor;
|
|
|
|
float8 analyze_scale_factor;
|
2009-02-09 21:57:59 +01:00
|
|
|
} AutoVacOpts;
|
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
typedef struct StdRdOptions
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* varlena header (do not touch directly!) */
|
2006-10-04 02:30:14 +02:00
|
|
|
int fillfactor; /* page fill factor in percent (0..100) */
|
Skip full index scan during cleanup of B-tree indexes when possible
Vacuum of index consists from two stages: multiple (zero of more) ambulkdelete
calls and one amvacuumcleanup call. When workload on particular table
is append-only, then autovacuum isn't intended to touch this table. However,
user may run vacuum manually in order to fill visibility map and get benefits
of index-only scans. Then ambulkdelete wouldn't be called for indexes
of such table (because no heap tuples were deleted), only amvacuumcleanup would
be called In this case, amvacuumcleanup would perform full index scan for
two objectives: put recyclable pages into free space map and update index
statistics.
This patch allows btvacuumclanup to skip full index scan when two conditions
are satisfied: no pages are going to be put into free space map and index
statistics isn't stalled. In order to check first condition, we store
oldest btpo_xact in the meta-page. When it's precedes RecentGlobalXmin, then
there are some recyclable pages. In order to check second condition we store
number of heap tuples observed during previous full index scan by cleanup.
If fraction of newly inserted tuples is less than
vacuum_cleanup_index_scale_factor, then statistics isn't considered to be
stalled. vacuum_cleanup_index_scale_factor can be defined as both reloption and GUC (default).
This patch bumps B-tree meta-page version. Upgrade of meta-page is performed
"on the fly": during VACUUM meta-page is rewritten with new version. No special
handling in pg_upgrade is required.
Author: Masahiko Sawada, Alexander Korotkov
Review by: Peter Geoghegan, Kyotaro Horiguchi, Alexander Korotkov, Yura Sokolov
Discussion: https://www.postgresql.org/message-id/flat/CAD21AoAX+d2oD_nrd9O2YkpzHaFr=uQeGr9s1rKC3O4ENc568g@mail.gmail.com
2018-04-04 18:29:00 +02:00
|
|
|
/* fraction of newly inserted tuples prior to trigger index cleanup */
|
|
|
|
float8 vacuum_cleanup_index_scale_factor;
|
2017-11-19 23:50:10 +01:00
|
|
|
int toast_tuple_target; /* target for tuple toasting */
|
2009-06-11 16:49:15 +02:00
|
|
|
AutoVacOpts autovacuum; /* autovacuum-related options */
|
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
|
|
|
bool user_catalog_table; /* use as an additional catalog relation */
|
|
|
|
int parallel_workers; /* max number of parallel workers */
|
2006-07-04 00:45:41 +02:00
|
|
|
} StdRdOptions;
|
|
|
|
|
|
|
|
#define HEAP_MIN_FILLFACTOR 10
|
|
|
|
#define HEAP_DEFAULT_FILLFACTOR 100
|
|
|
|
|
2017-11-19 23:50:10 +01:00
|
|
|
/*
|
|
|
|
* RelationGetToastTupleTarget
|
|
|
|
* Returns the relation's toast_tuple_target. Note multiple eval of argument!
|
|
|
|
*/
|
|
|
|
#define RelationGetToastTupleTarget(relation, defaulttarg) \
|
|
|
|
((relation)->rd_options ? \
|
|
|
|
((StdRdOptions *) (relation)->rd_options)->toast_tuple_target : (defaulttarg))
|
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
/*
|
|
|
|
* RelationGetFillFactor
|
|
|
|
* Returns the relation's fillfactor. Note multiple eval of argument!
|
|
|
|
*/
|
|
|
|
#define RelationGetFillFactor(relation, defaultff) \
|
|
|
|
((relation)->rd_options ? \
|
|
|
|
((StdRdOptions *) (relation)->rd_options)->fillfactor : (defaultff))
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationGetTargetPageUsage
|
|
|
|
* Returns the relation's desired space usage per page in bytes.
|
|
|
|
*/
|
|
|
|
#define RelationGetTargetPageUsage(relation, defaultff) \
|
|
|
|
(BLCKSZ * RelationGetFillFactor(relation, defaultff) / 100)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationGetTargetPageFreeSpace
|
|
|
|
* Returns the relation's desired freespace per page in bytes.
|
|
|
|
*/
|
|
|
|
#define RelationGetTargetPageFreeSpace(relation, defaultff) \
|
|
|
|
(BLCKSZ * (100 - RelationGetFillFactor(relation, defaultff)) / 100)
|
|
|
|
|
2014-07-14 23:24:40 +02:00
|
|
|
/*
|
|
|
|
* RelationIsUsedAsCatalogTable
|
|
|
|
* Returns whether the relation should be treated as a catalog table
|
2016-06-09 17:16:26 +02:00
|
|
|
* from the pov of logical decoding. Note multiple eval of argument!
|
2014-07-14 23:24:40 +02:00
|
|
|
*/
|
|
|
|
#define RelationIsUsedAsCatalogTable(relation) \
|
2016-11-10 21:00:58 +01:00
|
|
|
((relation)->rd_options && \
|
|
|
|
((relation)->rd_rel->relkind == RELKIND_RELATION || \
|
|
|
|
(relation)->rd_rel->relkind == RELKIND_MATVIEW) ? \
|
2014-07-14 23:24:40 +02:00
|
|
|
((StdRdOptions *) (relation)->rd_options)->user_catalog_table : false)
|
|
|
|
|
2016-04-08 17:14:56 +02:00
|
|
|
/*
|
2016-06-09 17:16:26 +02:00
|
|
|
* RelationGetParallelWorkers
|
|
|
|
* Returns the relation's parallel_workers reloption setting.
|
|
|
|
* Note multiple eval of argument!
|
2016-04-08 17:14:56 +02:00
|
|
|
*/
|
2016-06-09 17:16:26 +02:00
|
|
|
#define RelationGetParallelWorkers(relation, defaultpw) \
|
2016-04-08 17:14:56 +02:00
|
|
|
((relation)->rd_options ? \
|
2016-06-09 17:16:26 +02:00
|
|
|
((StdRdOptions *) (relation)->rd_options)->parallel_workers : (defaultpw))
|
2016-04-08 17:14:56 +02:00
|
|
|
|
2014-07-14 23:24:40 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ViewOptions
|
|
|
|
* Contents of rd_options for views
|
|
|
|
*/
|
|
|
|
typedef struct ViewOptions
|
|
|
|
{
|
|
|
|
int32 vl_len_; /* varlena header (do not touch directly!) */
|
|
|
|
bool security_barrier;
|
|
|
|
int check_option_offset;
|
|
|
|
} ViewOptions;
|
|
|
|
|
2011-12-22 22:15:57 +01:00
|
|
|
/*
|
|
|
|
* RelationIsSecurityView
|
2014-07-14 23:24:40 +02:00
|
|
|
* Returns whether the relation is security view, or not. Note multiple
|
|
|
|
* eval of argument!
|
2011-12-22 22:15:57 +01:00
|
|
|
*/
|
|
|
|
#define RelationIsSecurityView(relation) \
|
|
|
|
((relation)->rd_options ? \
|
2014-07-14 23:24:40 +02:00
|
|
|
((ViewOptions *) (relation)->rd_options)->security_barrier : false)
|
2011-12-22 22:15:57 +01:00
|
|
|
|
2013-07-18 23:10:16 +02:00
|
|
|
/*
|
|
|
|
* RelationHasCheckOption
|
|
|
|
* Returns true if the relation is a view defined with either the local
|
2014-07-14 23:24:40 +02:00
|
|
|
* or the cascaded check option. Note multiple eval of argument!
|
2013-07-18 23:10:16 +02:00
|
|
|
*/
|
|
|
|
#define RelationHasCheckOption(relation) \
|
|
|
|
((relation)->rd_options && \
|
2014-07-14 23:24:40 +02:00
|
|
|
((ViewOptions *) (relation)->rd_options)->check_option_offset != 0)
|
2013-07-18 23:10:16 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationHasLocalCheckOption
|
|
|
|
* Returns true if the relation is a view defined with the local check
|
2014-07-14 23:24:40 +02:00
|
|
|
* option. Note multiple eval of argument!
|
2013-07-18 23:10:16 +02:00
|
|
|
*/
|
|
|
|
#define RelationHasLocalCheckOption(relation) \
|
|
|
|
((relation)->rd_options && \
|
2014-07-14 23:24:40 +02:00
|
|
|
((ViewOptions *) (relation)->rd_options)->check_option_offset != 0 ? \
|
2013-07-18 23:10:16 +02:00
|
|
|
strcmp((char *) (relation)->rd_options + \
|
2014-07-14 23:24:40 +02:00
|
|
|
((ViewOptions *) (relation)->rd_options)->check_option_offset, \
|
2013-07-18 23:10:16 +02:00
|
|
|
"local") == 0 : false)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationHasCascadedCheckOption
|
|
|
|
* Returns true if the relation is a view defined with the cascaded check
|
2014-07-14 23:24:40 +02:00
|
|
|
* option. Note multiple eval of argument!
|
2013-07-18 23:10:16 +02:00
|
|
|
*/
|
|
|
|
#define RelationHasCascadedCheckOption(relation) \
|
|
|
|
((relation)->rd_options && \
|
2014-07-14 23:24:40 +02:00
|
|
|
((ViewOptions *) (relation)->rd_options)->check_option_offset != 0 ? \
|
2013-07-18 23:10:16 +02:00
|
|
|
strcmp((char *) (relation)->rd_options + \
|
2014-07-14 23:24:40 +02:00
|
|
|
((ViewOptions *) (relation)->rd_options)->check_option_offset, \
|
2013-07-18 23:10:16 +02:00
|
|
|
"cascaded") == 0 : false)
|
|
|
|
|
2013-12-11 01:17:34 +01:00
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* RelationIsValid
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff relation descriptor is valid.
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#define RelationIsValid(relation) PointerIsValid(relation)
|
1996-08-28 03:59:28 +02:00
|
|
|
|
1999-09-18 21:08:25 +02:00
|
|
|
#define InvalidRelation ((Relation) NULL)
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* RelationHasReferenceCountZero
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff relation reference count is zero.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
* Note:
|
1997-09-07 07:04:48 +02:00
|
|
|
* Assumes relation descriptor is valid.
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
|
|
|
#define RelationHasReferenceCountZero(relation) \
|
1997-09-07 07:04:48 +02:00
|
|
|
((bool)((relation)->rd_refcnt == 0))
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* RelationGetForm
|
2000-01-31 05:35:57 +01:00
|
|
|
* Returns pg_class tuple for a relation.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
* Note:
|
1997-09-07 07:04:48 +02:00
|
|
|
* Assumes relation descriptor is valid.
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
1998-09-01 05:29:17 +02:00
|
|
|
#define RelationGetForm(relation) ((relation)->rd_rel)
|
1996-08-28 03:59:28 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* RelationGetRelid
|
2004-01-06 19:07:32 +01:00
|
|
|
* Returns the OID of the relation
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
1998-08-19 04:04:17 +02:00
|
|
|
#define RelationGetRelid(relation) ((relation)->rd_id)
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/*
|
1999-09-18 21:08:25 +02:00
|
|
|
* RelationGetNumberOfAttributes
|
2018-04-07 22:00:39 +02:00
|
|
|
* Returns the total number of attributes in a relation.
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
|
|
|
#define RelationGetNumberOfAttributes(relation) ((relation)->rd_rel->relnatts)
|
|
|
|
|
2018-04-07 22:00:39 +02:00
|
|
|
/*
|
|
|
|
* IndexRelationGetNumberOfAttributes
|
|
|
|
* Returns the number of attributes in an index.
|
|
|
|
*/
|
|
|
|
#define IndexRelationGetNumberOfAttributes(relation) \
|
|
|
|
((relation)->rd_index->indnatts)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* IndexRelationGetNumberOfKeyAttributes
|
|
|
|
* Returns the number of key attributes in an index.
|
|
|
|
*/
|
|
|
|
#define IndexRelationGetNumberOfKeyAttributes(relation) \
|
|
|
|
((relation)->rd_index->indnkeyatts)
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* RelationGetDescr
|
1997-09-07 07:04:48 +02:00
|
|
|
* Returns tuple descriptor for a relation.
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
1998-09-01 05:29:17 +02:00
|
|
|
#define RelationGetDescr(relation) ((relation)->rd_att)
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2001-06-19 14:03:41 +02:00
|
|
|
/*
|
|
|
|
* RelationGetRelationName
|
2004-01-06 19:07:32 +01:00
|
|
|
* Returns the rel's name.
|
2001-06-19 14:03:41 +02:00
|
|
|
*
|
2002-03-31 08:26:32 +02:00
|
|
|
* Note that the name is only unique within the containing namespace.
|
2001-06-19 14:03:41 +02:00
|
|
|
*/
|
|
|
|
#define RelationGetRelationName(relation) \
|
2002-03-31 08:26:32 +02:00
|
|
|
(NameStr((relation)->rd_rel->relname))
|
2001-06-19 14:03:41 +02:00
|
|
|
|
2002-03-26 20:17:02 +01:00
|
|
|
/*
|
|
|
|
* RelationGetNamespace
|
2004-01-06 19:07:32 +01:00
|
|
|
* Returns the rel's namespace OID.
|
2002-03-26 20:17:02 +01:00
|
|
|
*/
|
|
|
|
#define RelationGetNamespace(relation) \
|
|
|
|
((relation)->rd_rel->relnamespace)
|
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
/*
|
|
|
|
* RelationIsMapped
|
2019-01-04 18:51:17 +01:00
|
|
|
* True if the relation uses the relfilenode map. Note multiple eval
|
|
|
|
* of argument!
|
2010-02-07 21:48:13 +01:00
|
|
|
*/
|
|
|
|
#define RelationIsMapped(relation) \
|
2019-01-04 18:51:17 +01:00
|
|
|
(RELKIND_HAS_STORAGE((relation)->rd_rel->relkind) && \
|
|
|
|
((relation)->rd_rel->relfilenode == InvalidOid))
|
2010-02-07 21:48:13 +01:00
|
|
|
|
2005-01-10 21:02:24 +01:00
|
|
|
/*
|
|
|
|
* RelationOpenSmgr
|
|
|
|
* Open the relation at the smgr level, if not already done.
|
|
|
|
*/
|
|
|
|
#define RelationOpenSmgr(relation) \
|
|
|
|
do { \
|
|
|
|
if ((relation)->rd_smgr == NULL) \
|
2010-08-13 22:10:54 +02:00
|
|
|
smgrsetowner(&((relation)->rd_smgr), smgropen((relation)->rd_node, (relation)->rd_backend)); \
|
2005-01-10 21:02:24 +01:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationCloseSmgr
|
|
|
|
* Close the relation at the smgr level, if not already done.
|
|
|
|
*
|
|
|
|
* Note: smgrclose should unhook from owner pointer, hence the Assert.
|
|
|
|
*/
|
|
|
|
#define RelationCloseSmgr(relation) \
|
|
|
|
do { \
|
|
|
|
if ((relation)->rd_smgr != NULL) \
|
|
|
|
{ \
|
|
|
|
smgrclose((relation)->rd_smgr); \
|
|
|
|
Assert((relation)->rd_smgr == NULL); \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2010-02-09 22:43:30 +01:00
|
|
|
/*
|
|
|
|
* RelationGetTargetBlock
|
|
|
|
* Fetch relation's current insertion target block.
|
|
|
|
*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Returns InvalidBlockNumber if there is no current target block. Note
|
2010-02-09 22:43:30 +01:00
|
|
|
* that the target block status is discarded on any smgr-level invalidation.
|
|
|
|
*/
|
|
|
|
#define RelationGetTargetBlock(relation) \
|
|
|
|
( (relation)->rd_smgr != NULL ? (relation)->rd_smgr->smgr_targblock : InvalidBlockNumber )
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationSetTargetBlock
|
|
|
|
* Set relation's current insertion target block.
|
|
|
|
*/
|
|
|
|
#define RelationSetTargetBlock(relation, targblock) \
|
|
|
|
do { \
|
|
|
|
RelationOpenSmgr(relation); \
|
|
|
|
(relation)->rd_smgr->smgr_targblock = (targblock); \
|
|
|
|
} while (0)
|
|
|
|
|
2010-12-13 18:34:26 +01:00
|
|
|
/*
|
|
|
|
* RelationNeedsWAL
|
|
|
|
* True if relation needs WAL.
|
|
|
|
*/
|
|
|
|
#define RelationNeedsWAL(relation) \
|
|
|
|
((relation)->rd_rel->relpersistence == RELPERSISTENCE_PERMANENT)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationUsesLocalBuffers
|
|
|
|
* True if relation's pages are stored in local buffers.
|
|
|
|
*/
|
|
|
|
#define RelationUsesLocalBuffers(relation) \
|
|
|
|
((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP)
|
|
|
|
|
2004-08-28 22:31:44 +02:00
|
|
|
/*
|
|
|
|
* RELATION_IS_LOCAL
|
|
|
|
* If a rel is either temp or newly created in the current transaction,
|
2012-12-18 02:15:32 +01:00
|
|
|
* it can be assumed to be accessible only to the current backend.
|
|
|
|
* This is typically used to decide that we can skip acquiring locks.
|
2004-08-28 22:31:44 +02:00
|
|
|
*
|
|
|
|
* Beware of multiple eval of argument
|
|
|
|
*/
|
|
|
|
#define RELATION_IS_LOCAL(relation) \
|
2012-12-18 02:15:32 +01:00
|
|
|
((relation)->rd_islocaltemp || \
|
2004-09-16 18:58:44 +02:00
|
|
|
(relation)->rd_createSubid != InvalidSubTransactionId)
|
2004-08-28 22:31:44 +02:00
|
|
|
|
2009-04-01 00:12:48 +02:00
|
|
|
/*
|
|
|
|
* RELATION_IS_OTHER_TEMP
|
|
|
|
* Test for a temporary relation that belongs to some other session.
|
|
|
|
*
|
|
|
|
* Beware of multiple eval of argument
|
|
|
|
*/
|
|
|
|
#define RELATION_IS_OTHER_TEMP(relation) \
|
2012-12-18 02:15:32 +01:00
|
|
|
((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP && \
|
|
|
|
!(relation)->rd_islocaltemp)
|
2009-04-01 00:12:48 +02:00
|
|
|
|
2013-04-09 20:02:49 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationIsScannable
|
2013-05-29 22:58:43 +02:00
|
|
|
* Currently can only be false for a materialized view which has not been
|
|
|
|
* populated by its query. This is likely to get more complicated later,
|
|
|
|
* so use a macro which looks like a function.
|
2013-04-09 20:02:49 +02:00
|
|
|
*/
|
2013-05-06 19:26:51 +02:00
|
|
|
#define RelationIsScannable(relation) ((relation)->rd_rel->relispopulated)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationIsPopulated
|
2013-05-29 22:58:43 +02:00
|
|
|
* Currently, we don't physically distinguish the "populated" and
|
2013-05-06 19:26:51 +02:00
|
|
|
* "scannable" properties of matviews, but that may change later.
|
|
|
|
* Hence, use the appropriate one of these macros in code tests.
|
|
|
|
*/
|
|
|
|
#define RelationIsPopulated(relation) ((relation)->rd_rel->relispopulated)
|
2013-04-09 20:02:49 +02:00
|
|
|
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
2013-12-11 00:33:45 +01:00
|
|
|
/*
|
|
|
|
* RelationIsAccessibleInLogicalDecoding
|
|
|
|
* True if we need to log enough information to have access via
|
|
|
|
* decoding snapshot.
|
|
|
|
*/
|
|
|
|
#define RelationIsAccessibleInLogicalDecoding(relation) \
|
|
|
|
(XLogLogicalInfoActive() && \
|
|
|
|
RelationNeedsWAL(relation) && \
|
2013-12-11 01:17:34 +01:00
|
|
|
(IsCatalogRelation(relation) || RelationIsUsedAsCatalogTable(relation)))
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
2013-12-11 00:33:45 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationIsLogicallyLogged
|
|
|
|
* True if we need to log enough information to extract the data from the
|
|
|
|
* WAL stream.
|
|
|
|
*
|
|
|
|
* We don't log information for unlogged tables (since they don't WAL log
|
|
|
|
* anyway) and for system tables (their content is hard to make sense of, and
|
2013-12-11 01:17:34 +01:00
|
|
|
* it would complicate decoding slightly for little gain). Note that we *do*
|
|
|
|
* log information for user defined catalog tables since they presumably are
|
|
|
|
* interesting to the user...
|
Add new wal_level, logical, sufficient for logical decoding.
When wal_level=logical, we'll log columns from the old tuple as
configured by the REPLICA IDENTITY facility added in commit
07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65. This makes it possible
a properly-configured logical replication solution to correctly
follow table updates even if they change the chosen key columns,
or, with REPLICA IDENTITY FULL, even if the table has no key at
all. Note that updates which do not modify the replica identity
column won't log anything extra, making the choice of a good key
(i.e. one that will rarely be changed) important to performance
when wal_level=logical is configured.
Each insert, update, or delete to a catalog table will also log
the CMIN and/or CMAX values of stamped by the current transaction.
This is necessary because logical decoding will require access to
historical snapshots of the catalog in order to decode some data
types, and the CMIN/CMAX values that we may need in order to judge
row visibility may have been overwritten by the time we need them.
Andres Freund, reviewed in various versions by myself, Heikki
Linnakangas, KONDO Mitsumasa, and many others.
2013-12-11 00:33:45 +01:00
|
|
|
*/
|
|
|
|
#define RelationIsLogicallyLogged(relation) \
|
|
|
|
(XLogLogicalInfoActive() && \
|
|
|
|
RelationNeedsWAL(relation) && \
|
|
|
|
!IsCatalogRelation(relation))
|
2013-04-09 20:02:49 +02:00
|
|
|
|
Implement table partitioning.
Table partitioning is like table inheritance and reuses much of the
existing infrastructure, but there are some important differences.
The parent is called a partitioned table and is always empty; it may
not have indexes or non-inherited constraints, since those make no
sense for a relation with no data of its own. The children are called
partitions and contain all of the actual data. Each partition has an
implicit partitioning constraint. Multiple inheritance is not
allowed, and partitioning and inheritance can't be mixed. Partitions
can't have extra columns and may not allow nulls unless the parent
does. Tuples inserted into the parent are automatically routed to the
correct partition, so tuple-routing ON INSERT triggers are not needed.
Tuple routing isn't yet supported for partitions which are foreign
tables, and it doesn't handle updates that cross partition boundaries.
Currently, tables can be range-partitioned or list-partitioned. List
partitioning is limited to a single column, but range partitioning can
involve multiple columns. A partitioning "column" can be an
expression.
Because table partitioning is less general than table inheritance, it
is hoped that it will be easier to reason about properties of
partitions, and therefore that this will serve as a better foundation
for a variety of possible optimizations, including query planner
optimizations. The tuple routing based which this patch does based on
the implicit partitioning constraints is an example of this, but it
seems likely that many other useful optimizations are also possible.
Amit Langote, reviewed and tested by Robert Haas, Ashutosh Bapat,
Amit Kapila, Rajkumar Raghuwanshi, Corey Huinker, Jaime Casanova,
Rushabh Lathia, Erik Rijkers, among others. Minor revisions by me.
2016-12-07 19:17:43 +01:00
|
|
|
/*
|
|
|
|
* RelationGetPartitionKey
|
|
|
|
* Returns the PartitionKey of a relation
|
|
|
|
*/
|
|
|
|
#define RelationGetPartitionKey(relation) ((relation)->rd_partkey)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RelationGetPartitionDesc
|
|
|
|
* Returns partition descriptor for a relation.
|
|
|
|
*/
|
|
|
|
#define RelationGetPartitionDesc(relation) ((relation)->rd_partdesc)
|
|
|
|
|
2004-07-17 05:32:14 +02:00
|
|
|
/* routines in utils/cache/relcache.c */
|
|
|
|
extern void RelationIncrementReferenceCount(Relation rel);
|
|
|
|
extern void RelationDecrementReferenceCount(Relation rel);
|
2016-05-06 14:47:12 +02:00
|
|
|
extern bool RelationHasUnloggedIndex(Relation rel);
|
2017-01-19 18:00:00 +01:00
|
|
|
extern List *RelationGetRepsetList(Relation rel);
|
2004-07-17 05:32:14 +02: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
|
|
|
#endif /* REL_H */
|