Introduce access/{table.h, relation.h}, for generic functions from heapam.h.
access/heapam contains functions that are very storage specific (say
heap_insert() and a lot of lower level functions), and fairly generic
infrastructure like relation_open(), heap_open() etc. In the upcoming
pluggable storage work we're introducing a layer between table
accesses in general and heapam, to allow for different storage
methods. For a bit cleaner separation it thus seems advantageous to
move generic functions like the aforementioned to their own headers.
access/relation.h will contain relation_open() etc, and access/table.h
will contain table_open() (formerly known as heap_open()). I've decided
for table.h not to include relation.h, but we might change that at a
later stage.
relation.h already exists in another directory, but the other
plausible name (rel.h) also conflicts. It'd be nice if there were a
non-conflicting name, but nobody came up with a suggestion. It's
possible that the appropriate way to address the naming conflict would
be to rename nodes/relation.h, which isn't particularly well named.
To avoid breaking a lot of extensions that just use heap_open() etc,
table.h has macros mapping the old names to the new ones, and heapam.h
includes relation, table.h. That also allows to keep the
bulk renaming of existing callers in a separate commit.
Author: Andres Freund
Discussion: https://postgr.es/m/20190111000539.xbv7s6w7ilcvm7dp@alap3.anarazel.de
2019-01-21 19:14:09 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* table.c
|
|
|
|
* Generic routines for table related code.
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
Introduce access/{table.h, relation.h}, for generic functions from heapam.h.
access/heapam contains functions that are very storage specific (say
heap_insert() and a lot of lower level functions), and fairly generic
infrastructure like relation_open(), heap_open() etc. In the upcoming
pluggable storage work we're introducing a layer between table
accesses in general and heapam, to allow for different storage
methods. For a bit cleaner separation it thus seems advantageous to
move generic functions like the aforementioned to their own headers.
access/relation.h will contain relation_open() etc, and access/table.h
will contain table_open() (formerly known as heap_open()). I've decided
for table.h not to include relation.h, but we might change that at a
later stage.
relation.h already exists in another directory, but the other
plausible name (rel.h) also conflicts. It'd be nice if there were a
non-conflicting name, but nobody came up with a suggestion. It's
possible that the appropriate way to address the naming conflict would
be to rename nodes/relation.h, which isn't particularly well named.
To avoid breaking a lot of extensions that just use heap_open() etc,
table.h has macros mapping the old names to the new ones, and heapam.h
includes relation, table.h. That also allows to keep the
bulk renaming of existing callers in a separate commit.
Author: Andres Freund
Discussion: https://postgr.es/m/20190111000539.xbv7s6w7ilcvm7dp@alap3.anarazel.de
2019-01-21 19:14:09 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/access/table/table.c
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* This file contains table_ routines that implement access to tables (in
|
|
|
|
* contrast to other relation types like indexes) that are independent of
|
|
|
|
* individual table access methods.
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/relation.h"
|
|
|
|
#include "access/table.h"
|
|
|
|
#include "storage/lmgr.h"
|
|
|
|
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* table_open - open a table relation by relation OID
|
|
|
|
*
|
|
|
|
* This is essentially relation_open plus check that the relation
|
|
|
|
* is not an index nor a composite type. (The caller should also
|
|
|
|
* check that it's not a view or foreign table before assuming it has
|
|
|
|
* storage.)
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
Relation
|
|
|
|
table_open(Oid relationId, LOCKMODE lockmode)
|
|
|
|
{
|
|
|
|
Relation r;
|
|
|
|
|
|
|
|
r = relation_open(relationId, lockmode);
|
|
|
|
|
|
|
|
if (r->rd_rel->relkind == RELKIND_INDEX ||
|
|
|
|
r->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is an index",
|
|
|
|
RelationGetRelationName(r))));
|
|
|
|
else if (r->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is a composite type",
|
|
|
|
RelationGetRelationName(r))));
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* table_openrv - open a table relation specified
|
|
|
|
* by a RangeVar node
|
|
|
|
*
|
|
|
|
* As above, but relation is specified by a RangeVar.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
Relation
|
|
|
|
table_openrv(const RangeVar *relation, LOCKMODE lockmode)
|
|
|
|
{
|
|
|
|
Relation r;
|
|
|
|
|
|
|
|
r = relation_openrv(relation, lockmode);
|
|
|
|
|
|
|
|
if (r->rd_rel->relkind == RELKIND_INDEX ||
|
|
|
|
r->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is an index",
|
|
|
|
RelationGetRelationName(r))));
|
|
|
|
else if (r->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is a composite type",
|
|
|
|
RelationGetRelationName(r))));
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* table_openrv_extended - open a table relation specified
|
|
|
|
* by a RangeVar node
|
|
|
|
*
|
|
|
|
* As above, but optionally return NULL instead of failing for
|
|
|
|
* relation-not-found.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
Relation
|
|
|
|
table_openrv_extended(const RangeVar *relation, LOCKMODE lockmode,
|
|
|
|
bool missing_ok)
|
|
|
|
{
|
|
|
|
Relation r;
|
|
|
|
|
|
|
|
r = relation_openrv_extended(relation, lockmode, missing_ok);
|
|
|
|
|
|
|
|
if (r)
|
|
|
|
{
|
|
|
|
if (r->rd_rel->relkind == RELKIND_INDEX ||
|
|
|
|
r->rd_rel->relkind == RELKIND_PARTITIONED_INDEX)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is an index",
|
|
|
|
RelationGetRelationName(r))));
|
|
|
|
else if (r->rd_rel->relkind == RELKIND_COMPOSITE_TYPE)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is a composite type",
|
|
|
|
RelationGetRelationName(r))));
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* table_close - close a table
|
|
|
|
*
|
|
|
|
* If lockmode is not "NoLock", we then release the specified lock.
|
|
|
|
*
|
|
|
|
* Note that it is often sensible to hold a lock beyond relation_close;
|
|
|
|
* in that case, the lock is released automatically at xact end.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
table_close(Relation relation, LOCKMODE lockmode)
|
|
|
|
{
|
|
|
|
relation_close(relation, lockmode);
|
|
|
|
}
|