postgresql/src/include/access/tupdesc.h

140 lines
4.6 KiB
C
Raw Normal View History

/*-------------------------------------------------------------------------
*
* tupdesc.h
* POSTGRES tuple descriptor definitions.
*
*
2017-01-03 19:48:53 +01:00
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
2010-09-20 22:08:53 +02:00
* src/include/access/tupdesc.h
*
*-------------------------------------------------------------------------
*/
#ifndef TUPDESC_H
#define TUPDESC_H
#include "access/attnum.h"
#include "catalog/pg_attribute.h"
1999-07-16 19:07:40 +02:00
#include "nodes/pg_list.h"
typedef struct attrDefault
{
AttrNumber adnum;
char *adbin; /* nodeToString representation of expr */
1997-09-08 22:59:27 +02:00
} AttrDefault;
1997-08-21 06:10:25 +02:00
typedef struct constrCheck
{
char *ccname;
char *ccbin; /* nodeToString representation of expr */
bool ccvalid;
bool ccnoinherit; /* this is a non-inheritable constraint */
} ConstrCheck;
1997-08-21 06:10:25 +02:00
/* This structure contains constraints of a tuple */
typedef struct tupleConstr
{
AttrDefault *defval; /* array */
ConstrCheck *check; /* array */
uint16 num_defval;
uint16 num_check;
bool has_not_null;
} TupleConstr;
1997-08-21 06:10:25 +02:00
/*
* This struct is passed around within the backend to describe the structure
* of tuples. For tuples coming from on-disk relations, the information is
* collected from the pg_attribute, pg_attrdef, and pg_constraint catalogs.
* Transient row types (such as the result of a join query) have anonymous
* TupleDesc structs that generally omit any constraint info; therefore the
* structure is designed to let the constraints be omitted efficiently.
*
* Note that only user attributes, not system attributes, are mentioned in
* TupleDesc; with the exception that tdhasoid indicates if OID is present.
*
* If the tupdesc is known to correspond to a named rowtype (such as a table's
* rowtype) then tdtypeid identifies that type and tdtypmod is -1. Otherwise
* tdtypeid is RECORDOID, and tdtypmod can be either -1 for a fully anonymous
* row type, or a value >= 0 to allow the rowtype to be looked up in the
* typcache.c type cache.
*
* Tuple descriptors that live in caches (relcache or typcache, at present)
* are reference-counted: they can be deleted when their reference count goes
* to zero. Tuple descriptors created by the executor need no reference
* counting, however: they are simply created in the appropriate memory
* context and go away when the context is freed. We set the tdrefcount
* field of such a descriptor to -1, while reference-counted descriptors
* always have tdrefcount >= 0.
1997-08-21 06:10:25 +02:00
*/
typedef struct tupleDesc
{
int natts; /* number of attributes in the tuple */
Oid tdtypeid; /* composite type ID for tuple type */
int32 tdtypmod; /* typmod for tuple type */
bool tdhasoid; /* tuple has oid attribute in its header */
int tdrefcount; /* reference count, or -1 if not counting */
TupleConstr *constr; /* constraints, or NULL if none */
/* attrs[N] is the description of Attribute Number N+1 */
FormData_pg_attribute attrs[FLEXIBLE_ARRAY_MEMBER];
2017-06-21 20:39:04 +02:00
} *TupleDesc;
/* Accessor for the i'th attribute of tupdesc. */
#define TupleDescAttr(tupdesc, i) (&(tupdesc)->attrs[(i)])
extern TupleDesc CreateTemplateTupleDesc(int natts, bool hasoid);
extern TupleDesc CreateTupleDesc(int natts, bool hasoid,
2002-09-04 22:31:48 +02:00
Form_pg_attribute *attrs);
extern TupleDesc CreateTupleDescCopy(TupleDesc tupdesc);
extern TupleDesc CreateTupleDescCopyConstr(TupleDesc tupdesc);
extern void TupleDescCopyEntry(TupleDesc dst, AttrNumber dstAttno,
TupleDesc src, AttrNumber srcAttno);
extern void FreeTupleDesc(TupleDesc tupdesc);
extern void IncrTupleDescRefCount(TupleDesc tupdesc);
extern void DecrTupleDescRefCount(TupleDesc tupdesc);
#define PinTupleDesc(tupdesc) \
do { \
if ((tupdesc)->tdrefcount >= 0) \
IncrTupleDescRefCount(tupdesc); \
} while (0)
#define ReleaseTupleDesc(tupdesc) \
do { \
if ((tupdesc)->tdrefcount >= 0) \
DecrTupleDescRefCount(tupdesc); \
} while (0)
2006-10-04 02:30:14 +02:00
extern bool equalTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2);
extern void TupleDescInitEntry(TupleDesc desc,
AttrNumber attributeNumber,
const char *attributeName,
Oid oidtypeid,
int32 typmod,
int attdim);
extern void TupleDescInitBuiltinEntry(TupleDesc desc,
AttrNumber attributeNumber,
const char *attributeName,
Oid oidtypeid,
int32 typmod,
int attdim);
extern void TupleDescInitEntryCollation(TupleDesc desc,
2011-04-10 17:42:00 +02:00
AttrNumber attributeNumber,
Oid collationid);
extern TupleDesc BuildDescForRelation(List *schema);
extern TupleDesc BuildDescFromLists(List *names, List *types, List *typmods, List *collations);
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 /* TUPDESC_H */