2002-04-15 01:22:04 -04:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
|
|
|
|
* tablecmds.h
|
|
|
|
|
* prototypes for tablecmds.c.
|
|
|
|
|
*
|
|
|
|
|
*
|
2018-01-02 23:30:12 -05:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2002-04-15 01:22:04 -04:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
2010-09-20 16:08:53 -04:00
|
|
|
* src/include/commands/tablecmds.h
|
2002-04-15 01:22:04 -04:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef TABLECMDS_H
|
|
|
|
|
#define TABLECMDS_H
|
|
|
|
|
|
2011-08-22 23:19:21 -04:00
|
|
|
#include "access/htup.h"
|
2012-10-31 09:52:55 -04:00
|
|
|
#include "catalog/dependency.h"
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 12:10:50 -05:00
|
|
|
#include "catalog/objectaddress.h"
|
2002-04-15 01:22:04 -04:00
|
|
|
#include "nodes/parsenodes.h"
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 17:28:04 -04:00
|
|
|
#include "catalog/partition.h"
|
2010-07-28 01:22:24 -04:00
|
|
|
#include "storage/lock.h"
|
2008-06-18 20:46:06 -04:00
|
|
|
#include "utils/relcache.h"
|
2002-04-15 01:22:04 -04:00
|
|
|
|
|
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 12:10:50 -05:00
|
|
|
extern ObjectAddress DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
|
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 13:17:43 -05:00
|
|
|
ObjectAddress *typaddress, const char *queryString);
|
2002-04-15 01:22:04 -04:00
|
|
|
|
2008-06-14 14:04:34 -04:00
|
|
|
extern void RemoveRelations(DropStmt *drop);
|
2002-04-15 01:22:04 -04:00
|
|
|
|
2012-01-06 22:42:26 -05:00
|
|
|
extern Oid AlterTableLookupRelation(AlterTableStmt *stmt, LOCKMODE lockmode);
|
|
|
|
|
|
|
|
|
|
extern void AlterTable(Oid relid, LOCKMODE lockmode, AlterTableStmt *stmt);
|
2002-04-15 01:22:04 -04:00
|
|
|
|
2010-07-28 01:22:24 -04:00
|
|
|
extern LOCKMODE AlterTableGetLockLevel(List *cmds);
|
|
|
|
|
|
|
|
|
|
extern void ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing, LOCKMODE lockmode);
|
2005-11-21 07:49:33 -05:00
|
|
|
|
2004-05-05 00:48:48 -04:00
|
|
|
extern void AlterTableInternal(Oid relid, List *cmds, bool recurse);
|
2003-03-20 13:52:48 -05:00
|
|
|
|
2014-08-21 19:06:17 -04:00
|
|
|
extern Oid AlterTableMoveAll(AlterTableMoveAllStmt *stmt);
|
|
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 12:10:50 -05:00
|
|
|
extern ObjectAddress AlterTableNamespace(AlterObjectSchemaStmt *stmt,
|
|
|
|
|
Oid *oldschema);
|
2005-08-01 00:03:59 -04:00
|
|
|
|
2012-10-31 09:52:55 -04:00
|
|
|
extern void AlterTableNamespaceInternal(Relation rel, Oid oldNspOid,
|
|
|
|
|
Oid nspOid, ObjectAddresses *objsMoved);
|
|
|
|
|
|
2005-08-01 00:03:59 -04:00
|
|
|
extern void AlterRelationNamespaceInternal(Relation classRel, Oid relOid,
|
2005-10-14 22:49:52 -04:00
|
|
|
Oid oldNspOid, Oid newNspOid,
|
2012-10-31 09:52:55 -04:00
|
|
|
bool hasDependEntry,
|
|
|
|
|
ObjectAddresses *objsMoved);
|
2005-08-01 00:03:59 -04:00
|
|
|
|
2008-01-30 14:46:48 -05:00
|
|
|
extern void CheckTableNotInUse(Relation rel, const char *stmt);
|
|
|
|
|
|
2006-03-02 22:30:54 -05:00
|
|
|
extern void ExecuteTruncate(TruncateStmt *stmt);
|
2002-04-15 01:22:04 -04:00
|
|
|
|
2011-09-02 14:29:31 -04:00
|
|
|
extern void SetRelationHasSubclass(Oid relationId, bool relhassubclass);
|
|
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 12:10:50 -05:00
|
|
|
extern ObjectAddress renameatt(RenameStmt *stmt);
|
2002-04-15 01:22:04 -04:00
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 12:10:50 -05:00
|
|
|
extern ObjectAddress renameatt_type(RenameStmt *stmt);
|
2012-03-10 13:19:13 -05:00
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 12:10:50 -05:00
|
|
|
extern ObjectAddress RenameConstraint(RenameStmt *stmt);
|
|
|
|
|
|
|
|
|
|
extern ObjectAddress RenameRelation(RenameStmt *stmt);
|
2002-04-15 01:22:04 -04:00
|
|
|
|
2008-03-19 14:38:30 -04:00
|
|
|
extern void RenameRelationInternal(Oid myrelid,
|
2013-03-17 22:55:14 -04:00
|
|
|
const char *newrelname, bool is_internal);
|
2008-03-19 14:38:30 -04:00
|
|
|
|
2007-05-11 16:17:15 -04:00
|
|
|
extern void find_composite_type_dependencies(Oid typeOid,
|
2011-02-11 08:47:38 -05:00
|
|
|
Relation origRelation,
|
|
|
|
|
const char *origTypeName);
|
2007-05-11 16:17:15 -04:00
|
|
|
|
2011-04-20 21:35:15 -04:00
|
|
|
extern void check_of_type(HeapTuple typetuple);
|
|
|
|
|
|
2002-11-11 17:19:25 -05:00
|
|
|
extern void register_on_commit_action(Oid relid, OnCommitAction action);
|
|
|
|
|
extern void remove_on_commit_action(Oid relid);
|
2002-11-09 18:56:39 -05:00
|
|
|
|
2002-11-11 17:19:25 -05:00
|
|
|
extern void PreCommit_on_commit_actions(void);
|
2004-09-16 12:58:44 -04:00
|
|
|
extern void AtEOXact_on_commit_actions(bool isCommit);
|
2004-06-30 20:52:04 -04:00
|
|
|
extern void AtEOSubXact_on_commit_actions(bool isCommit,
|
2005-10-14 22:49:52 -04:00
|
|
|
SubTransactionId mySubid,
|
|
|
|
|
SubTransactionId parentSubid);
|
2002-11-09 18:56:39 -05:00
|
|
|
|
2011-12-21 15:17:28 -05:00
|
|
|
extern void RangeVarCallbackOwnsTable(const RangeVar *relation,
|
2012-06-10 15:20:04 -04:00
|
|
|
Oid relId, Oid oldRelId, void *arg);
|
2011-12-21 15:17:28 -05:00
|
|
|
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 09:33:31 -05:00
|
|
|
extern void RangeVarCallbackOwnsRelation(const RangeVar *relation,
|
2014-05-06 12:12:18 -04:00
|
|
|
Oid relId, Oid oldRelId, void *noCatalogs);
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 17:28:04 -04:00
|
|
|
extern bool PartConstraintImpliedByRelConstraint(Relation scanrel,
|
|
|
|
|
List *partConstraint);
|
|
|
|
|
|
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 15:18:54 -04:00
|
|
|
#endif /* TABLECMDS_H */
|