1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* heap.h
|
2001-10-23 00:47:57 +02:00
|
|
|
* prototypes for functions in backend/catalog/heap.c
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/heap.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef HEAP_H
|
|
|
|
#define HEAP_H
|
|
|
|
|
2008-11-14 02:57:42 +01:00
|
|
|
#include "catalog/indexing.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 18:10:50 +01:00
|
|
|
#include "catalog/objectaddress.h"
|
|
|
|
#include "parser/parse_node.h"
|
1996-11-05 12:23:43 +01:00
|
|
|
|
2002-03-26 20:17:02 +01:00
|
|
|
|
1999-10-04 01:55:40 +02:00
|
|
|
typedef struct RawColumnDefault
|
|
|
|
{
|
|
|
|
AttrNumber attnum; /* attribute to attach default to */
|
2005-10-15 04:49:52 +02:00
|
|
|
Node *raw_default; /* default value (untransformed parse tree) */
|
2018-03-28 02:13:52 +02:00
|
|
|
bool missingMode; /* true if part of add column processing */
|
1999-10-04 01:55:40 +02:00
|
|
|
} RawColumnDefault;
|
|
|
|
|
2004-05-05 06:48:48 +02:00
|
|
|
typedef struct CookedConstraint
|
|
|
|
{
|
|
|
|
ConstrType contype; /* CONSTR_DEFAULT or CONSTR_CHECK */
|
2015-03-25 21:17:56 +01:00
|
|
|
Oid conoid; /* constr OID if created, otherwise Invalid */
|
2004-05-05 06:48:48 +02:00
|
|
|
char *name; /* name, or NULL if none */
|
|
|
|
AttrNumber attnum; /* which attr (only for DEFAULT) */
|
|
|
|
Node *expr; /* transformed default or check expr */
|
2011-06-02 00:43:50 +02:00
|
|
|
bool skip_validation; /* skip validation? (only for CHECK) */
|
2008-05-10 01:32:05 +02:00
|
|
|
bool is_local; /* constraint has local (non-inherited) def */
|
|
|
|
int inhcount; /* number of times constraint is inherited */
|
2012-04-21 04:46:20 +02:00
|
|
|
bool is_no_inherit; /* constraint has local def and cannot be
|
|
|
|
* inherited */
|
2004-05-05 06:48:48 +02:00
|
|
|
} CookedConstraint;
|
|
|
|
|
2002-03-31 08:26:32 +02:00
|
|
|
extern Relation heap_create(const char *relname,
|
|
|
|
Oid relnamespace,
|
2004-06-18 08:14:31 +02:00
|
|
|
Oid reltablespace,
|
2005-04-14 03:38:22 +02:00
|
|
|
Oid relid,
|
2011-07-18 17:02:48 +02:00
|
|
|
Oid relfilenode,
|
2002-03-26 20:17:02 +01:00
|
|
|
TupleDesc tupDesc,
|
2004-08-31 19:10:36 +02:00
|
|
|
char relkind,
|
2010-12-13 18:34:26 +01:00
|
|
|
char relpersistence,
|
2002-04-27 23:24:34 +02:00
|
|
|
bool shared_relation,
|
2013-06-03 16:22:31 +02:00
|
|
|
bool mapped_relation,
|
|
|
|
bool allow_system_table_mods);
|
2000-07-04 08:11:54 +02:00
|
|
|
|
2002-03-31 08:26:32 +02:00
|
|
|
extern Oid heap_create_with_catalog(const char *relname,
|
|
|
|
Oid relnamespace,
|
2004-06-18 08:14:31 +02:00
|
|
|
Oid reltablespace,
|
2005-04-14 03:38:22 +02:00
|
|
|
Oid relid,
|
2009-09-27 00:42:03 +02:00
|
|
|
Oid reltypeid,
|
2010-01-29 00:21:13 +01:00
|
|
|
Oid reloftypeid,
|
2005-08-26 05:08:15 +02:00
|
|
|
Oid ownerid,
|
2002-03-26 20:17:02 +01:00
|
|
|
TupleDesc tupdesc,
|
2008-05-10 01:32:05 +02:00
|
|
|
List *cooked_constraints,
|
2002-03-31 08:26:32 +02:00
|
|
|
char relkind,
|
2010-12-13 18:34:26 +01:00
|
|
|
char relpersistence,
|
2002-04-27 23:24:34 +02:00
|
|
|
bool shared_relation,
|
2010-02-07 21:48:13 +01:00
|
|
|
bool mapped_relation,
|
2004-03-23 20:35:17 +01:00
|
|
|
bool oidislocal,
|
|
|
|
int oidinhcount,
|
2002-11-11 23:19:25 +01:00
|
|
|
OnCommitAction oncommit,
|
2006-07-04 00:45:41 +02:00
|
|
|
Datum reloptions,
|
2009-10-05 21:24:49 +02:00
|
|
|
bool use_user_acl,
|
2012-10-23 23:07:26 +02:00
|
|
|
bool allow_system_table_mods,
|
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 18:10:50 +01:00
|
|
|
bool is_internal,
|
2018-03-21 14:13:24 +01:00
|
|
|
Oid relrewrite,
|
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 18:10:50 +01:00
|
|
|
ObjectAddress *typaddress);
|
2000-07-04 08:11:54 +02:00
|
|
|
|
2012-05-11 15:46:42 +02:00
|
|
|
extern void heap_create_init_fork(Relation rel);
|
|
|
|
|
2004-08-28 23:05:26 +02:00
|
|
|
extern void heap_drop_with_catalog(Oid relid);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2005-01-27 04:19:37 +01:00
|
|
|
extern void heap_truncate(List *relids);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2009-08-23 21:23:41 +02:00
|
|
|
extern void heap_truncate_one_rel(Relation rel);
|
|
|
|
|
2005-01-27 04:19:37 +01:00
|
|
|
extern void heap_truncate_check_FKs(List *relations, bool tempTables);
|
2003-09-19 23:04:20 +02:00
|
|
|
|
2006-03-03 04:30:54 +01:00
|
|
|
extern List *heap_truncate_find_FKs(List *relationIds);
|
|
|
|
|
2008-11-14 02:57:42 +01:00
|
|
|
extern void InsertPgAttributeTuple(Relation pg_attribute_rel,
|
2009-06-11 16:49:15 +02:00
|
|
|
Form_pg_attribute new_attribute,
|
|
|
|
CatalogIndexState indstate);
|
2008-11-14 02:57:42 +01:00
|
|
|
|
2006-07-04 00:45:41 +02:00
|
|
|
extern void InsertPgClassTuple(Relation pg_class_desc,
|
|
|
|
Relation new_rel_desc,
|
|
|
|
Oid new_rel_oid,
|
2009-10-05 21:24:49 +02:00
|
|
|
Datum relacl,
|
2006-07-04 00:45:41 +02:00
|
|
|
Datum reloptions);
|
|
|
|
|
2008-05-10 01:32:05 +02:00
|
|
|
extern List *AddRelationNewConstraints(Relation rel,
|
|
|
|
List *newColDefaults,
|
|
|
|
List *newConstraints,
|
|
|
|
bool allow_merge,
|
2013-03-18 03:55:14 +01:00
|
|
|
bool is_local,
|
|
|
|
bool is_internal);
|
1999-10-04 01:55:40 +02:00
|
|
|
|
2018-03-28 02:13:52 +02:00
|
|
|
extern void RelationClearMissing(Relation rel);
|
|
|
|
|
2015-03-25 21:17:56 +01:00
|
|
|
extern Oid StoreAttrDefault(Relation rel, AttrNumber attnum,
|
2018-03-28 02:13:52 +02:00
|
|
|
Node *expr, bool is_internal,
|
|
|
|
bool add_column_mode);
|
2004-05-05 06:48:48 +02:00
|
|
|
|
2002-03-20 20:45:13 +01:00
|
|
|
extern Node *cookDefault(ParseState *pstate,
|
2002-09-04 22:31:48 +02:00
|
|
|
Node *raw_default,
|
|
|
|
Oid atttypid,
|
|
|
|
int32 atttypmod,
|
2017-10-31 15:34:31 +01:00
|
|
|
const char *attname);
|
2002-03-19 03:18:25 +01:00
|
|
|
|
2002-07-14 23:08:08 +02:00
|
|
|
extern void DeleteRelationTuple(Oid relid);
|
|
|
|
extern void DeleteAttributeTuples(Oid relid);
|
2012-10-24 19:39:37 +02:00
|
|
|
extern void DeleteSystemAttributeTuples(Oid relid);
|
2002-08-02 20:15:10 +02:00
|
|
|
extern void RemoveAttributeById(Oid relid, AttrNumber attnum);
|
2002-07-15 18:33:32 +02:00
|
|
|
extern void RemoveAttrDefault(Oid relid, AttrNumber attnum,
|
2012-01-26 15:24:54 +01:00
|
|
|
DropBehavior behavior, bool complain, bool internal);
|
2002-07-15 18:33:32 +02:00
|
|
|
extern void RemoveAttrDefaultById(Oid attrdefId);
|
2004-08-28 23:05:26 +02:00
|
|
|
extern void RemoveStatistics(Oid relid, AttrNumber attnum);
|
2002-07-14 23:08:08 +02:00
|
|
|
|
2001-08-10 20:57:42 +02:00
|
|
|
extern Form_pg_attribute SystemAttributeDefinition(AttrNumber attno,
|
2001-10-25 07:50:21 +02:00
|
|
|
bool relhasoids);
|
2001-05-07 02:43:27 +02:00
|
|
|
|
2001-10-23 00:47:57 +02:00
|
|
|
extern Form_pg_attribute SystemAttributeByName(const char *attname,
|
2001-10-25 07:50:21 +02:00
|
|
|
bool relhasoids);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2010-02-07 21:48:13 +01:00
|
|
|
extern void CheckAttributeNamesTypes(TupleDesc tupdesc, char relkind,
|
2010-02-26 03:01:40 +01:00
|
|
|
bool allow_system_table_mods);
|
2002-12-16 19:39:22 +01:00
|
|
|
|
2011-03-28 21:44:54 +02:00
|
|
|
extern void CheckAttributeType(const char *attname,
|
|
|
|
Oid atttypid, Oid attcollation,
|
|
|
|
List *containing_rowtypes,
|
2010-02-26 03:01:40 +01:00
|
|
|
bool allow_system_table_mods);
|
2002-12-16 19:39:22 +01: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
|
|
|
/* pg_partitioned_table catalog manipulation functions */
|
|
|
|
extern void StorePartitionKey(Relation rel,
|
2017-01-24 16:20:02 +01:00
|
|
|
char strategy,
|
|
|
|
int16 partnatts,
|
|
|
|
AttrNumber *partattrs,
|
|
|
|
List *partexprs,
|
|
|
|
Oid *partopclass,
|
|
|
|
Oid *partcollation);
|
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
|
|
|
extern void RemovePartitionKeyByRelId(Oid relid);
|
Code review focused on new node types added by partitioning support.
Fix failure to check that we got a plain Const from const-simplification of
a coercion request. This is the cause of bug #14666 from Tian Bing: there
is an int4 to money cast, but it's only stable not immutable (because of
dependence on lc_monetary), resulting in a FuncExpr that the code was
miserably unequipped to deal with, or indeed even to notice that it was
failing to deal with. Add test cases around this coercion behavior.
In view of the above, sprinkle the code liberally with castNode() macros,
in hope of catching the next such bug a bit sooner. Also, change some
functions that were randomly declared to take Node* to take more specific
pointer types. And change some struct fields that were declared Node*
but could be given more specific types, allowing removal of assorted
explicit casts.
Place PARTITION_MAX_KEYS check a bit closer to the code it's protecting.
Likewise check only-one-key-for-list-partitioning restriction in a less
random place.
Avoid not-per-project-style usages like !strcmp(...).
Fix assorted failures to avoid scribbling on the input of parse
transformation. I'm not sure how necessary this is, but it's entirely
silly for these functions to be expending cycles to avoid that and not
getting it right.
Add guards against partitioning on system columns.
Put backend/nodes/ support code into an order that matches handling
of these node types elsewhere.
Annotate the fact that somebody added location fields to PartitionBoundSpec
and PartitionRangeDatum but forgot to handle them in
outfuncs.c/readfuncs.c. This is fairly harmless for production purposes
(since readfuncs.c would just substitute -1 anyway) but it's still bogus.
It's not worth forcing a post-beta1 initdb just to fix this, but if we
have another reason to force initdb before 10.0, we should go back and
clean this up.
Contrariwise, somebody added location fields to PartitionElem and
PartitionSpec but forgot to teach exprLocation() about them.
Consolidate duplicative code in transformPartitionBound().
Improve a couple of error messages.
Improve assorted commentary.
Re-pgindent the files touched by this patch; this affects a few comment
blocks that must have been added quite recently.
Report: https://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org
2017-05-29 05:20:28 +02:00
|
|
|
extern void StorePartitionBound(Relation rel, Relation parent,
|
|
|
|
PartitionBoundSpec *bound);
|
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
|
|
|
|
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 /* HEAP_H */
|