mirror of
https://github.com/postgres/postgres.git
synced 2025-08-28 18:48:04 +03:00
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD
This commit is contained in:
@@ -16,7 +16,7 @@
|
||||
|
||||
|
||||
/*
|
||||
* user defined attribute numbers start at 1. -ay 2/95
|
||||
* user defined attribute numbers start at 1. -ay 2/95
|
||||
*/
|
||||
typedef int16 AttrNumber;
|
||||
|
||||
|
@@ -92,7 +92,7 @@ typedef struct SysScanDescData *SysScanDesc;
|
||||
* blocking to see if a conflicting transaction commits.
|
||||
*
|
||||
* For deferrable unique constraints, UNIQUE_CHECK_PARTIAL is specified at
|
||||
* insertion time. The index AM should test if the tuple is unique, but
|
||||
* insertion time. The index AM should test if the tuple is unique, but
|
||||
* should not throw error, block, or prevent the insertion if the tuple
|
||||
* appears not to be unique. We'll recheck later when it is time for the
|
||||
* constraint to be enforced. The AM must return true if the tuple is
|
||||
@@ -101,7 +101,7 @@ typedef struct SysScanDescData *SysScanDesc;
|
||||
*
|
||||
* When it is time to recheck the deferred constraint, a pseudo-insertion
|
||||
* call is made with UNIQUE_CHECK_EXISTING. The tuple is already in the
|
||||
* index in this case, so it should not be inserted again. Rather, just
|
||||
* index in this case, so it should not be inserted again. Rather, just
|
||||
* check for conflicting live tuples (possibly blocking).
|
||||
*/
|
||||
typedef enum IndexUniqueCheck
|
||||
|
@@ -564,7 +564,7 @@ extern void ginPrepareDataScan(GinBtree btree, Relation index);
|
||||
*
|
||||
* In each GinScanKeyData, nentries is the true number of entries, while
|
||||
* nuserentries is the number that extractQueryFn returned (which is what
|
||||
* we report to consistentFn). The "user" entries must come first.
|
||||
* we report to consistentFn). The "user" entries must come first.
|
||||
*/
|
||||
typedef struct GinScanKeyData *GinScanKey;
|
||||
|
||||
|
@@ -184,7 +184,7 @@ typedef HashMetaPageData *HashMetaPage;
|
||||
#define ALL_SET ((uint32) ~0)
|
||||
|
||||
/*
|
||||
* Bitmap pages do not contain tuples. They do contain the standard
|
||||
* Bitmap pages do not contain tuples. They do contain the standard
|
||||
* page headers and trailers; however, everything in between is a
|
||||
* giant bit array. The number of bits that fit on a page obviously
|
||||
* depends on the page size and the header/trailer overhead. We require
|
||||
|
@@ -69,7 +69,7 @@
|
||||
*
|
||||
* We store five "virtual" fields Xmin, Cmin, Xmax, Cmax, and Xvac in three
|
||||
* physical fields. Xmin and Xmax are always really stored, but Cmin, Cmax
|
||||
* and Xvac share a field. This works because we know that Cmin and Cmax
|
||||
* and Xvac share a field. This works because we know that Cmin and Cmax
|
||||
* are only interesting for the lifetime of the inserting and deleting
|
||||
* transaction respectively. If a tuple is inserted and deleted in the same
|
||||
* transaction, we store a "combo" command id that can be mapped to the real
|
||||
@@ -81,7 +81,7 @@
|
||||
* ie, an insert-in-progress or delete-in-progress tuple.)
|
||||
*
|
||||
* A word about t_ctid: whenever a new tuple is stored on disk, its t_ctid
|
||||
* is initialized with its own TID (location). If the tuple is ever updated,
|
||||
* is initialized with its own TID (location). If the tuple is ever updated,
|
||||
* its t_ctid is changed to point to the replacement version of the tuple.
|
||||
* Thus, a tuple is the latest version of its row iff XMAX is invalid or
|
||||
* t_ctid points to itself (in which case, if XMAX is valid, the tuple is
|
||||
@@ -96,10 +96,10 @@
|
||||
* check fails, one may assume that there is no live descendant version.
|
||||
*
|
||||
* Following the fixed header fields, the nulls bitmap is stored (beginning
|
||||
* at t_bits). The bitmap is *not* stored if t_infomask shows that there
|
||||
* at t_bits). The bitmap is *not* stored if t_infomask shows that there
|
||||
* are no nulls in the tuple. If an OID field is present (as indicated by
|
||||
* t_infomask), then it is stored just before the user data, which begins at
|
||||
* the offset shown by t_hoff. Note that t_hoff must be a multiple of
|
||||
* the offset shown by t_hoff. Note that t_hoff must be a multiple of
|
||||
* MAXALIGN.
|
||||
*/
|
||||
|
||||
@@ -206,7 +206,7 @@ typedef HeapTupleHeaderData *HeapTupleHeader;
|
||||
/*
|
||||
* HeapTupleHeader accessor macros
|
||||
*
|
||||
* Note: beware of multiple evaluations of "tup" argument. But the Set
|
||||
* Note: beware of multiple evaluations of "tup" argument. But the Set
|
||||
* macros evaluate their other argument only once.
|
||||
*/
|
||||
|
||||
@@ -426,7 +426,7 @@ do { \
|
||||
* MinimalTuple is an alternative representation that is used for transient
|
||||
* tuples inside the executor, in places where transaction status information
|
||||
* is not required, the tuple rowtype is known, and shaving off a few bytes
|
||||
* is worthwhile because we need to store many tuples. The representation
|
||||
* is worthwhile because we need to store many tuples. The representation
|
||||
* is chosen so that tuple access routines can work with either full or
|
||||
* minimal tuples via a HeapTupleData pointer structure. The access routines
|
||||
* see no difference, except that they must not access the transaction status
|
||||
@@ -450,7 +450,7 @@ do { \
|
||||
* the MINIMAL_TUPLE_OFFSET distance. t_len does not include that, however.
|
||||
*
|
||||
* MINIMAL_TUPLE_DATA_OFFSET is the offset to the first useful (non-pad) data
|
||||
* other than the length word. tuplesort.c and tuplestore.c use this to avoid
|
||||
* other than the length word. tuplesort.c and tuplestore.c use this to avoid
|
||||
* writing the padding to disk.
|
||||
*/
|
||||
#define MINIMAL_TUPLE_OFFSET \
|
||||
@@ -502,12 +502,12 @@ typedef MinimalTupleData *MinimalTuple;
|
||||
* This is the output format of heap_form_tuple and related routines.
|
||||
*
|
||||
* * Separately allocated tuple: t_data points to a palloc'd chunk that
|
||||
* is not adjacent to the HeapTupleData. (This case is deprecated since
|
||||
* is not adjacent to the HeapTupleData. (This case is deprecated since
|
||||
* it's difficult to tell apart from case #1. It should be used only in
|
||||
* limited contexts where the code knows that case #1 will never apply.)
|
||||
*
|
||||
* * Separately allocated minimal tuple: t_data points MINIMAL_TUPLE_OFFSET
|
||||
* bytes before the start of a MinimalTuple. As with the previous case,
|
||||
* bytes before the start of a MinimalTuple. As with the previous case,
|
||||
* this can't be told apart from case #1 by inspection; code setting up
|
||||
* or destroying this representation has to know what it's doing.
|
||||
*
|
||||
@@ -600,7 +600,7 @@ typedef HeapTupleData *HeapTuple;
|
||||
*/
|
||||
#define XLOG_HEAP_INIT_PAGE 0x80
|
||||
/*
|
||||
* We ran out of opcodes, so heapam.c now has a second RmgrId. These opcodes
|
||||
* We ran out of opcodes, so heapam.c now has a second RmgrId. These opcodes
|
||||
* are associated with RM_HEAP2_ID, but are not logically different from
|
||||
* the ones above associated with RM_HEAP_ID. We apply XLOG_HEAP_OPMASK,
|
||||
* although currently XLOG_HEAP_INIT_PAGE is not used for any of these.
|
||||
@@ -826,7 +826,7 @@ extern Datum fastgetattr(HeapTuple tup, int attnum, TupleDesc tupleDesc,
|
||||
* and set *isnull == true. Otherwise, we set *isnull == false.
|
||||
*
|
||||
* <tup> is the pointer to the heap tuple. <attnum> is the attribute
|
||||
* number of the column (field) caller wants. <tupleDesc> is a
|
||||
* number of the column (field) caller wants. <tupleDesc> is a
|
||||
* pointer to the structure describing the row and all its fields.
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -22,7 +22,7 @@
|
||||
/*
|
||||
* Index tuple header structure
|
||||
*
|
||||
* All index tuples start with IndexTupleData. If the HasNulls bit is set,
|
||||
* All index tuples start with IndexTupleData. If the HasNulls bit is set,
|
||||
* this is followed by an IndexAttributeBitMapData. The index attribute
|
||||
* values follow, beginning at a MAXALIGN boundary.
|
||||
*
|
||||
|
@@ -36,9 +36,9 @@ typedef uint16 BTCycleId;
|
||||
* and status. If the page is deleted, we replace the level with the
|
||||
* next-transaction-ID value indicating when it is safe to reclaim the page.
|
||||
*
|
||||
* We also store a "vacuum cycle ID". When a page is split while VACUUM is
|
||||
* We also store a "vacuum cycle ID". When a page is split while VACUUM is
|
||||
* processing the index, a nonzero value associated with the VACUUM run is
|
||||
* stored into both halves of the split page. (If VACUUM is not running,
|
||||
* stored into both halves of the split page. (If VACUUM is not running,
|
||||
* both pages receive zero cycleids.) This allows VACUUM to detect whether
|
||||
* a page was split since it started, with a small probability of false match
|
||||
* if the page was last split some exact multiple of MAX_BT_CYCLE_ID VACUUMs
|
||||
@@ -75,7 +75,7 @@ typedef BTPageOpaqueData *BTPageOpaque;
|
||||
#define BTP_HAS_GARBAGE (1 << 6) /* page has LP_DEAD tuples */
|
||||
|
||||
/*
|
||||
* The max allowed value of a cycle ID is a bit less than 64K. This is
|
||||
* The max allowed value of a cycle ID is a bit less than 64K. This is
|
||||
* for convenience of pg_filedump and similar utilities: we want to use
|
||||
* the last 2 bytes of special space as an index type indicator, and
|
||||
* restricting cycle ID lets btree use that space for vacuum cycle IDs
|
||||
@@ -272,9 +272,9 @@ typedef struct xl_btree_insert
|
||||
* Note: the four XLOG_BTREE_SPLIT xl_info codes all use this data record.
|
||||
* The _L and _R variants indicate whether the inserted tuple went into the
|
||||
* left or right split page (and thus, whether newitemoff and the new item
|
||||
* are stored or not). The _ROOT variants indicate that we are splitting
|
||||
* are stored or not). The _ROOT variants indicate that we are splitting
|
||||
* the root page, and thus that a newroot record rather than an insert or
|
||||
* split record should follow. Note that a split record never carries a
|
||||
* split record should follow. Note that a split record never carries a
|
||||
* metapage update --- we'll do that in the parent-level update.
|
||||
*/
|
||||
typedef struct xl_btree_split
|
||||
@@ -287,13 +287,13 @@ typedef struct xl_btree_split
|
||||
OffsetNumber firstright; /* first item moved to right page */
|
||||
|
||||
/*
|
||||
* If level > 0, BlockIdData downlink follows. (We use BlockIdData rather
|
||||
* If level > 0, BlockIdData downlink follows. (We use BlockIdData rather
|
||||
* than BlockNumber for alignment reasons: SizeOfBtreeSplit is only 16-bit
|
||||
* aligned.)
|
||||
*
|
||||
* If level > 0, an IndexTuple representing the HIKEY of the left page
|
||||
* follows. We don't need this on leaf pages, because it's the same as
|
||||
* the leftmost key in the new right page. Also, it's suppressed if
|
||||
* the leftmost key in the new right page. Also, it's suppressed if
|
||||
* XLogInsert chooses to store the left page's whole page image.
|
||||
*
|
||||
* In the _L variants, next are OffsetNumber newitemoff and the new item.
|
||||
@@ -372,7 +372,7 @@ typedef struct xl_btree_vacuum
|
||||
/*
|
||||
* This is what we need to know about deletion of a btree page. The target
|
||||
* identifies the tuple removed from the parent page (note that we remove
|
||||
* this tuple's downlink and the *following* tuple's key). Note we do not
|
||||
* this tuple's downlink and the *following* tuple's key). Note we do not
|
||||
* store any content for the deleted page --- it is just rewritten as empty
|
||||
* during recovery, apart from resetting the btpo.xact.
|
||||
*/
|
||||
@@ -457,7 +457,7 @@ typedef BTStackData *BTStack;
|
||||
* BTScanOpaqueData is the btree-private state needed for an indexscan.
|
||||
* This consists of preprocessed scan keys (see _bt_preprocess_keys() for
|
||||
* details of the preprocessing), information about the current location
|
||||
* of the scan, and information about the marked location, if any. (We use
|
||||
* of the scan, and information about the marked location, if any. (We use
|
||||
* BTScanPosData to represent the data needed for each of current and marked
|
||||
* locations.) In addition we can remember some known-killed index entries
|
||||
* that must be marked before we can move off the current page.
|
||||
@@ -465,9 +465,9 @@ typedef BTStackData *BTStack;
|
||||
* Index scans work a page at a time: we pin and read-lock the page, identify
|
||||
* all the matching items on the page and save them in BTScanPosData, then
|
||||
* release the read-lock while returning the items to the caller for
|
||||
* processing. This approach minimizes lock/unlock traffic. Note that we
|
||||
* processing. This approach minimizes lock/unlock traffic. Note that we
|
||||
* keep the pin on the index page until the caller is done with all the items
|
||||
* (this is needed for VACUUM synchronization, see nbtree/README). When we
|
||||
* (this is needed for VACUUM synchronization, see nbtree/README). When we
|
||||
* are ready to step to the next page, if the caller has told us any of the
|
||||
* items were killed, we re-lock the page to mark them killed, then unlock.
|
||||
* Finally we drop the pin and step to the next page in the appropriate
|
||||
@@ -542,7 +542,7 @@ typedef BTScanOpaqueData *BTScanOpaque;
|
||||
|
||||
/*
|
||||
* We use some private sk_flags bits in preprocessed scan keys. We're allowed
|
||||
* to use bits 16-31 (see skey.h). The uppermost bits are copied from the
|
||||
* to use bits 16-31 (see skey.h). The uppermost bits are copied from the
|
||||
* index's indoption[] array entry for the index attribute.
|
||||
*/
|
||||
#define SK_BT_REQFWD 0x00010000 /* required to continue forward scan */
|
||||
|
@@ -194,7 +194,7 @@ typedef struct
|
||||
* "base" is a pointer to the reloptions structure, and "offset" is an integer
|
||||
* variable that must be initialized to sizeof(reloptions structure). This
|
||||
* struct must have been allocated with enough space to hold any string option
|
||||
* present, including terminating \0 for every option. SET_VARSIZE() must be
|
||||
* present, including terminating \0 for every option. SET_VARSIZE() must be
|
||||
* called on the struct with this offset as the second argument, after all the
|
||||
* string options have been processed.
|
||||
*/
|
||||
|
@@ -42,7 +42,7 @@ typedef uint16 StrategyNumber;
|
||||
|
||||
/*
|
||||
* A ScanKey represents the application of a comparison operator between
|
||||
* a table or index column and a constant. When it's part of an array of
|
||||
* a table or index column and a constant. When it's part of an array of
|
||||
* ScanKeys, the comparison conditions are implicitly ANDed. The index
|
||||
* column is the left argument of the operator, if it's a binary operator.
|
||||
* (The data structure can support unary indexable operators too; in that
|
||||
@@ -106,7 +106,7 @@ typedef ScanKeyData *ScanKey;
|
||||
* must be sorted according to the leading column number.
|
||||
*
|
||||
* The subsidiary ScanKey array appears in logical column order of the row
|
||||
* comparison, which may be different from index column order. The array
|
||||
* comparison, which may be different from index column order. The array
|
||||
* elements are like a normal ScanKey array except that:
|
||||
* sk_flags must include SK_ROW_MEMBER, plus SK_ROW_END in the last
|
||||
* element (needed since row header does not include a count)
|
||||
|
@@ -31,7 +31,7 @@
|
||||
* segment and page numbers in SimpleLruTruncate (see PagePrecedes()).
|
||||
*
|
||||
* Note: slru.c currently assumes that segment file names will be four hex
|
||||
* digits. This sets a lower bound on the segment size (64K transactions
|
||||
* digits. This sets a lower bound on the segment size (64K transactions
|
||||
* for 32-bit TransactionIds).
|
||||
*/
|
||||
#define SLRU_PAGES_PER_SEGMENT 32
|
||||
|
@@ -69,7 +69,7 @@
|
||||
* using the OID generator. (We start the generator at 10000.)
|
||||
*
|
||||
* OIDs beginning at 16384 are assigned from the OID generator
|
||||
* during normal multiuser operation. (We force the generator up to
|
||||
* during normal multiuser operation. (We force the generator up to
|
||||
* 16384 as soon as we are in normal operation.)
|
||||
*
|
||||
* The choices of 10000 and 16384 are completely arbitrary, and can be moved
|
||||
|
@@ -53,7 +53,7 @@ typedef struct tupleConstr
|
||||
* 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
|
||||
* 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.
|
||||
|
@@ -92,7 +92,7 @@
|
||||
|
||||
/*
|
||||
* att_align_datum aligns the given offset as needed for a datum of alignment
|
||||
* requirement attalign and typlen attlen. attdatum is the Datum variable
|
||||
* requirement attalign and typlen attlen. attdatum is the Datum variable
|
||||
* we intend to pack into a tuple (it's only accessed if we are dealing with
|
||||
* a varlena type). Note that this assumes the Datum will be stored as-is;
|
||||
* callers that are intending to convert non-short varlena datums to short
|
||||
@@ -111,7 +111,7 @@
|
||||
* pointer; when accessing a varlena field we have to "peek" to see if we
|
||||
* are looking at a pad byte or the first byte of a 1-byte-header datum.
|
||||
* (A zero byte must be either a pad byte, or the first byte of a correctly
|
||||
* aligned 4-byte length word; in either case we can align safely. A non-zero
|
||||
* aligned 4-byte length word; in either case we can align safely. A non-zero
|
||||
* byte must be either a 1-byte length word, or the first byte of a correctly
|
||||
* aligned 4-byte length word; in either case we need not align.)
|
||||
*
|
||||
|
@@ -60,7 +60,7 @@
|
||||
* The code will also consider moving MAIN data out-of-line, but only as a
|
||||
* last resort if the previous steps haven't reached the target tuple size.
|
||||
* In this phase we use a different target size, currently equal to the
|
||||
* largest tuple that will fit on a heap page. This is reasonable since
|
||||
* largest tuple that will fit on a heap page. This is reasonable since
|
||||
* the user has told us to keep the data in-line if at all possible.
|
||||
*/
|
||||
#define TOAST_TUPLES_PER_PAGE_MAIN 1
|
||||
@@ -76,7 +76,7 @@
|
||||
|
||||
/*
|
||||
* When we store an oversize datum externally, we divide it into chunks
|
||||
* containing at most TOAST_MAX_CHUNK_SIZE data bytes. This number *must*
|
||||
* containing at most TOAST_MAX_CHUNK_SIZE data bytes. This number *must*
|
||||
* be small enough that the completed toast-table tuple (including the
|
||||
* ID and sequence fields and all overhead) will fit on a page.
|
||||
* The coding here sets the size on the theory that we want to fit
|
||||
|
@@ -32,11 +32,11 @@
|
||||
* where there can be zero to three backup blocks (as signaled by xl_info flag
|
||||
* bits). XLogRecord structs always start on MAXALIGN boundaries in the WAL
|
||||
* files, and we round up SizeOfXLogRecord so that the rmgr data is also
|
||||
* guaranteed to begin on a MAXALIGN boundary. However, no padding is added
|
||||
* guaranteed to begin on a MAXALIGN boundary. However, no padding is added
|
||||
* to align BkpBlock structs or backup block data.
|
||||
*
|
||||
* NOTE: xl_len counts only the rmgr data, not the XLogRecord header,
|
||||
* and also not any backup blocks. xl_tot_len counts everything. Neither
|
||||
* and also not any backup blocks. xl_tot_len counts everything. Neither
|
||||
* length field is rounded up to an alignment boundary.
|
||||
*/
|
||||
typedef struct XLogRecord
|
||||
@@ -115,7 +115,7 @@ extern int sync_method;
|
||||
* value (ignoring InvalidBuffer) appearing in the rdata chain.
|
||||
*
|
||||
* When buffer is valid, caller must set buffer_std to indicate whether the
|
||||
* page uses standard pd_lower/pd_upper header fields. If this is true, then
|
||||
* page uses standard pd_lower/pd_upper header fields. If this is true, then
|
||||
* XLOG is allowed to omit the free space between pd_lower and pd_upper from
|
||||
* the backed-up page image. Note that even when buffer_std is false, the
|
||||
* page MUST have an LSN field as its first eight bytes!
|
||||
|
@@ -50,7 +50,7 @@ typedef struct BkpBlock
|
||||
|
||||
/*
|
||||
* When there is not enough space on current page for whole record, we
|
||||
* continue on the next page with continuation record. (However, the
|
||||
* continue on the next page with continuation record. (However, the
|
||||
* XLogRecord header will never be split across pages; if there's less than
|
||||
* SizeOfXLogRecord space left at the end of a page, we just waste it.)
|
||||
*
|
||||
@@ -168,7 +168,7 @@ typedef XLogLongPageHeaderData *XLogLongPageHeader;
|
||||
* Compute ID and segment from an XLogRecPtr.
|
||||
*
|
||||
* For XLByteToSeg, do the computation at face value. For XLByteToPrevSeg,
|
||||
* a boundary byte is taken to be in the previous segment. This is suitable
|
||||
* a boundary byte is taken to be in the previous segment. This is suitable
|
||||
* for deciding which segment to write given a pointer to a record end,
|
||||
* for example. (We can assume xrecoff is not zero, since no valid recptr
|
||||
* can have that.)
|
||||
|
@@ -25,8 +25,8 @@
|
||||
* NOTE: the "log file number" is somewhat misnamed, since the actual files
|
||||
* making up the XLOG are much smaller than 4Gb. Each actual file is an
|
||||
* XLogSegSize-byte "segment" of a logical log file having the indicated
|
||||
* xlogid. The log file number and segment number together identify a
|
||||
* physical XLOG file. Segment number and offset within the physical file
|
||||
* xlogid. The log file number and segment number together identify a
|
||||
* physical XLOG file. Segment number and offset within the physical file
|
||||
* are computed from xrecoff div and mod XLogSegSize.
|
||||
*/
|
||||
typedef struct XLogRecPtr
|
||||
@@ -88,7 +88,7 @@ typedef uint32 TimeLineID;
|
||||
* read those buffers except during crash recovery or if wal_level != minimal,
|
||||
* it is a win to use it in all cases where we sync on each write(). We could
|
||||
* allow O_DIRECT with fsync(), but it is unclear if fsync() could process
|
||||
* writes not buffered in the kernel. Also, O_DIRECT is never enough to force
|
||||
* writes not buffered in the kernel. Also, O_DIRECT is never enough to force
|
||||
* data to the drives, it merely tries to bypass the kernel cache, so we still
|
||||
* need O_SYNC/O_DSYNC.
|
||||
*/
|
||||
@@ -101,7 +101,7 @@ typedef uint32 TimeLineID;
|
||||
/*
|
||||
* This chunk of hackery attempts to determine which file sync methods
|
||||
* are available on the current platform, and to choose an appropriate
|
||||
* default method. We assume that fsync() is always available, and that
|
||||
* default method. We assume that fsync() is always available, and that
|
||||
* configure determined whether fdatasync() is.
|
||||
*/
|
||||
#if defined(O_SYNC)
|
||||
|
@@ -36,7 +36,7 @@
|
||||
* 8) system-specific hacks
|
||||
*
|
||||
* NOTE: since this file is included by both frontend and backend modules, it's
|
||||
* almost certainly wrong to put an "extern" declaration here. typedefs and
|
||||
* almost certainly wrong to put an "extern" declaration here. typedefs and
|
||||
* macros are the kind of thing that might go here.
|
||||
*
|
||||
*----------------------------------------------------------------
|
||||
@@ -106,7 +106,7 @@
|
||||
|
||||
/*
|
||||
* Use this to mark string constants as needing translation at some later
|
||||
* time, rather than immediately. This is useful for cases where you need
|
||||
* time, rather than immediately. This is useful for cases where you need
|
||||
* access to the original string and translated string, and for cases where
|
||||
* immediate translation is not possible, like when initializing global
|
||||
* variables.
|
||||
@@ -382,7 +382,7 @@ typedef struct
|
||||
* Variable-length datatypes all share the 'struct varlena' header.
|
||||
*
|
||||
* NOTE: for TOASTable types, this is an oversimplification, since the value
|
||||
* may be compressed or moved out-of-line. However datatype-specific routines
|
||||
* may be compressed or moved out-of-line. However datatype-specific routines
|
||||
* are mostly content to deal with de-TOASTed values only, and of course
|
||||
* client-side routines should never see a TOASTed value. But even in a
|
||||
* de-TOASTed value, beware of touching vl_len_ directly, as its representation
|
||||
@@ -412,7 +412,7 @@ typedef struct varlena VarChar; /* var-length char, ie SQL varchar(n) */
|
||||
/*
|
||||
* Specialized array types. These are physically laid out just the same
|
||||
* as regular arrays (so that the regular array subscripting code works
|
||||
* with them). They exist as distinct types mostly for historical reasons:
|
||||
* with them). They exist as distinct types mostly for historical reasons:
|
||||
* they have nonstandard I/O behavior which we don't want to change for fear
|
||||
* of breaking applications that look at the system catalogs. There is also
|
||||
* an implementation issue for oidvector: it's part of the primary key for
|
||||
@@ -455,7 +455,7 @@ typedef NameData *Name;
|
||||
|
||||
/*
|
||||
* Support macros for escaping strings. escape_backslash should be TRUE
|
||||
* if generating a non-standard-conforming string. Prefixing a string
|
||||
* if generating a non-standard-conforming string. Prefixing a string
|
||||
* with ESCAPE_STRING_SYNTAX guarantees it is non-standard-conforming.
|
||||
* Beware of multiple evaluation of the "ch" argument!
|
||||
*/
|
||||
@@ -584,7 +584,7 @@ typedef NameData *Name;
|
||||
* datum) and add a null, do not do it with StrNCpy(..., len+1). That
|
||||
* might seem to work, but it fetches one byte more than there is in the
|
||||
* text object. One fine day you'll have a SIGSEGV because there isn't
|
||||
* another byte before the end of memory. Don't laugh, we've had real
|
||||
* another byte before the end of memory. Don't laugh, we've had real
|
||||
* live bug reports from real live users over exactly this mistake.
|
||||
* Do it honestly with "memcpy(dst,src,len); dst[len] = '\0';", instead.
|
||||
*/
|
||||
@@ -610,7 +610,7 @@ typedef NameData *Name;
|
||||
* Exactly the same as standard library function memset(), but considerably
|
||||
* faster for zeroing small word-aligned structures (such as parsetree nodes).
|
||||
* This has to be a macro because the main point is to avoid function-call
|
||||
* overhead. However, we have also found that the loop is faster than
|
||||
* overhead. However, we have also found that the loop is faster than
|
||||
* native libc memset() on some platforms, even those with assembler
|
||||
* memset() functions. More research needs to be done, perhaps with
|
||||
* MEMSET_LOOP_LIMIT tests in configure.
|
||||
@@ -740,7 +740,7 @@ typedef NameData *Name;
|
||||
* Section 8: system-specific hacks
|
||||
*
|
||||
* This should be limited to things that absolutely have to be
|
||||
* included in every source file. The port-specific header file
|
||||
* included in every source file. The port-specific header file
|
||||
* is usually a better place for this sort of thing.
|
||||
* ----------------------------------------------------------------
|
||||
*/
|
||||
@@ -749,7 +749,7 @@ typedef NameData *Name;
|
||||
* NOTE: this is also used for opening text files.
|
||||
* WIN32 treats Control-Z as EOF in files opened in text mode.
|
||||
* Therefore, we open files in binary mode on Win32 so we can read
|
||||
* literal control-Z. The other affect is that we see CRLF, but
|
||||
* literal control-Z. The other affect is that we see CRLF, but
|
||||
* that is OK because we can already handle those cleanly.
|
||||
*/
|
||||
#if defined(WIN32) || defined(__CYGWIN__)
|
||||
|
@@ -4,7 +4,7 @@
|
||||
* "Catalog version number" for PostgreSQL.
|
||||
*
|
||||
* The catalog version number is used to flag incompatible changes in
|
||||
* the PostgreSQL system catalogs. Whenever anyone changes the format of
|
||||
* the PostgreSQL system catalogs. Whenever anyone changes the format of
|
||||
* a system catalog relation, or adds, deletes, or modifies standard
|
||||
* catalog entries in such a way that an updated backend wouldn't work
|
||||
* with an old database (or vice versa), the catalog version number
|
||||
|
@@ -59,7 +59,7 @@
|
||||
* DEPENDENCY_PIN ('p'): there is no dependent object; this type of entry
|
||||
* is a signal that the system itself depends on the referenced object,
|
||||
* and so that object must never be deleted. Entries of this type are
|
||||
* created only during initdb. The fields for the dependent object
|
||||
* created only during initdb. The fields for the dependent object
|
||||
* contain zeroes.
|
||||
*
|
||||
* Other dependency flavors may be needed in future.
|
||||
|
@@ -19,7 +19,7 @@
|
||||
|
||||
/*
|
||||
* This structure holds a list of possible functions or operators
|
||||
* found by namespace lookup. Each function/operator is identified
|
||||
* found by namespace lookup. Each function/operator is identified
|
||||
* by OID and by argument types; the list must be pruned by type
|
||||
* resolution rules that are embodied in the parser, not here.
|
||||
* See FuncnameGetCandidates's comments for more info.
|
||||
|
@@ -12,7 +12,7 @@
|
||||
|
||||
/*
|
||||
* Object access hooks are intended to be called just before or just after
|
||||
* performing certain actions on a SQL object. This is intended as
|
||||
* performing certain actions on a SQL object. This is intended as
|
||||
* infrastructure for security or logging pluggins.
|
||||
*
|
||||
* OAT_POST_CREATE should be invoked just after the the object is created.
|
||||
|
@@ -22,7 +22,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_attrdef definition. cpp turns this into
|
||||
* pg_attrdef definition. cpp turns this into
|
||||
* typedef struct FormData_pg_attrdef
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -160,7 +160,7 @@ CATALOG(pg_attribute,1249) BKI_BOOTSTRAP BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
|
||||
|
||||
/*
|
||||
* ATTRIBUTE_FIXED_PART_SIZE is the size of the fixed-layout,
|
||||
* guaranteed-not-null part of a pg_attribute row. This is in fact as much
|
||||
* guaranteed-not-null part of a pg_attribute row. This is in fact as much
|
||||
* of the row as gets copied into tuple descriptors, so don't expect you
|
||||
* can access fields beyond attcollation except in a real tuple!
|
||||
*/
|
||||
|
@@ -26,7 +26,7 @@
|
||||
/*
|
||||
* The CATALOG definition has to refer to the type of rolvaliduntil as
|
||||
* "timestamptz" (lower case) so that bootstrap mode recognizes it. But
|
||||
* the C header files define this type as TimestampTz. Since the field is
|
||||
* the C header files define this type as TimestampTz. Since the field is
|
||||
* potentially-null and therefore can't be accessed directly from C code,
|
||||
* there is no particular need for the C struct definition to show the
|
||||
* field type as TimestampTz --- instead we just make it int.
|
||||
|
@@ -38,7 +38,7 @@ CATALOG(pg_constraint,2606)
|
||||
* relations. This is partly for backwards compatibility with past
|
||||
* Postgres practice, and partly because we don't want to have to obtain a
|
||||
* global lock to generate a globally unique name for a nameless
|
||||
* constraint. We associate a namespace with constraint names only for
|
||||
* constraint. We associate a namespace with constraint names only for
|
||||
* SQL-spec compatibility.
|
||||
*/
|
||||
NameData conname; /* name of this constraint */
|
||||
@@ -57,7 +57,7 @@ CATALOG(pg_constraint,2606)
|
||||
|
||||
/*
|
||||
* contypid links to the pg_type row for a domain if this is a domain
|
||||
* constraint. Otherwise it's 0.
|
||||
* constraint. Otherwise it's 0.
|
||||
*
|
||||
* For SQL-style global ASSERTIONs, both conrelid and contypid would be
|
||||
* zero. This is not presently supported, however.
|
||||
@@ -76,7 +76,7 @@ CATALOG(pg_constraint,2606)
|
||||
|
||||
/*
|
||||
* These fields, plus confkey, are only meaningful for a foreign-key
|
||||
* constraint. Otherwise confrelid is 0 and the char fields are spaces.
|
||||
* constraint. Otherwise confrelid is 0 and the char fields are spaces.
|
||||
*/
|
||||
Oid confrelid; /* relation referenced by foreign key */
|
||||
char confupdtype; /* foreign key's ON UPDATE action */
|
||||
|
@@ -94,9 +94,9 @@ typedef struct ControlFileData
|
||||
uint64 system_identifier;
|
||||
|
||||
/*
|
||||
* Version identifier information. Keep these fields at the same offset,
|
||||
* Version identifier information. Keep these fields at the same offset,
|
||||
* especially pg_control_version; they won't be real useful if they move
|
||||
* around. (For historical reasons they must be 8 bytes into the file
|
||||
* around. (For historical reasons they must be 8 bytes into the file
|
||||
* rather than immediately at the front.)
|
||||
*
|
||||
* pg_control_version identifies the format of pg_control itself.
|
||||
|
@@ -27,7 +27,7 @@
|
||||
#include "utils/relcache.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_db_role_setting definition. cpp turns this into
|
||||
* pg_db_role_setting definition. cpp turns this into
|
||||
* typedef struct FormData_pg_db_role_setting
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -21,7 +21,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_default_acl definition. cpp turns this into
|
||||
* pg_default_acl definition. cpp turns this into
|
||||
* typedef struct FormData_pg_default_acl
|
||||
* ----------------
|
||||
*/
|
||||
@@ -65,7 +65,7 @@ typedef FormData_pg_default_acl *Form_pg_default_acl;
|
||||
|
||||
/*
|
||||
* Types of objects for which the user is allowed to specify default
|
||||
* permissions through pg_default_acl. These codes are used in the
|
||||
* permissions through pg_default_acl. These codes are used in the
|
||||
* defaclobjtype column.
|
||||
*/
|
||||
#define DEFACLOBJ_RELATION 'r' /* table, view */
|
||||
|
@@ -6,12 +6,12 @@
|
||||
* NOTE: an object is identified by the OID of the row that primarily
|
||||
* defines the object, plus the OID of the table that that row appears in.
|
||||
* For example, a function is identified by the OID of its pg_proc row
|
||||
* plus the pg_class OID of table pg_proc. This allows unique identification
|
||||
* plus the pg_class OID of table pg_proc. This allows unique identification
|
||||
* of objects without assuming that OIDs are unique across tables.
|
||||
*
|
||||
* Since attributes don't have OIDs of their own, we identify an attribute
|
||||
* comment by the objoid+classoid of its parent table, plus an "objsubid"
|
||||
* giving the attribute column number. "objsubid" must be zero in a comment
|
||||
* giving the attribute column number. "objsubid" must be zero in a comment
|
||||
* for a table itself, so that it is distinct from any column comment.
|
||||
* Currently, objsubid is unused and zero for all other kinds of objects,
|
||||
* but perhaps it might be useful someday to associate comments with
|
||||
@@ -39,7 +39,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_description definition. cpp turns this into
|
||||
* pg_description definition. cpp turns this into
|
||||
* typedef struct FormData_pg_description
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -22,7 +22,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_largeobject definition. cpp turns this into
|
||||
* pg_largeobject definition. cpp turns this into
|
||||
* typedef struct FormData_pg_largeobject
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -17,10 +17,10 @@
|
||||
* don't support partial indexes on system catalogs.)
|
||||
*
|
||||
* Normally opckeytype = InvalidOid (zero), indicating that the data stored
|
||||
* in the index is the same as the data in the indexed column. If opckeytype
|
||||
* in the index is the same as the data in the indexed column. If opckeytype
|
||||
* is nonzero then it indicates that a conversion step is needed to produce
|
||||
* the stored index data, which will be of type opckeytype (which might be
|
||||
* the same or different from the input datatype). Performing such a
|
||||
* the same or different from the input datatype). Performing such a
|
||||
* conversion is the responsibility of the index access method --- not all
|
||||
* AMs support this.
|
||||
*
|
||||
@@ -42,7 +42,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_opclass definition. cpp turns this into
|
||||
* pg_opclass definition. cpp turns this into
|
||||
* typedef struct FormData_pg_opclass
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -1401,7 +1401,7 @@ DESCR("natural exponential (e^x)");
|
||||
|
||||
/*
|
||||
* This form of obj_description is now deprecated, since it will fail if
|
||||
* OIDs are not unique across system catalogs. Use the other form instead.
|
||||
* OIDs are not unique across system catalogs. Use the other form instead.
|
||||
*/
|
||||
DATA(insert OID = 1348 ( obj_description PGNSP PGUID 14 100 0 0 f f f t f s 1 0 25 "26" _null_ _null_ _null_ _null_ "select description from pg_catalog.pg_description where objoid = $1 and objsubid = 0" _null_ _null_ _null_ ));
|
||||
DESCR("deprecated, use two-argument form instead");
|
||||
@@ -4339,7 +4339,7 @@ DESCR("fetch the Nth row value");
|
||||
#define PROVOLATILE_VOLATILE 'v' /* can change even within a scan */
|
||||
|
||||
/*
|
||||
* Symbolic values for proargmodes column. Note that these must agree with
|
||||
* Symbolic values for proargmodes column. Note that these must agree with
|
||||
* the FunctionParameterMode enum in parsenodes.h; we declare them here to
|
||||
* be accessible from either header.
|
||||
*/
|
||||
|
@@ -25,7 +25,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_rewrite definition. cpp turns this into
|
||||
* pg_rewrite definition. cpp turns this into
|
||||
* typedef struct FormData_pg_rewrite
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -33,7 +33,7 @@ CATALOG(pg_shdepend,1214) BKI_SHARED_RELATION BKI_WITHOUT_OIDS
|
||||
/*
|
||||
* Identification of the dependent (referencing) object.
|
||||
*
|
||||
* These fields are all zeroes for a DEPENDENCY_PIN entry. Also, dbid can
|
||||
* These fields are all zeroes for a DEPENDENCY_PIN entry. Also, dbid can
|
||||
* be zero to denote a shared object.
|
||||
*/
|
||||
Oid dbid; /* OID of database containing object */
|
||||
|
@@ -7,7 +7,7 @@
|
||||
* NOTE: an object is identified by the OID of the row that primarily
|
||||
* defines the object, plus the OID of the table that that row appears in.
|
||||
* For example, a database is identified by the OID of its pg_database row
|
||||
* plus the pg_class OID of table pg_database. This allows unique
|
||||
* plus the pg_class OID of table pg_database. This allows unique
|
||||
* identification of objects without assuming that OIDs are unique
|
||||
* across tables.
|
||||
*
|
||||
@@ -32,7 +32,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_shdescription definition. cpp turns this into
|
||||
* pg_shdescription definition. cpp turns this into
|
||||
* typedef struct FormData_pg_shdescription
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -49,7 +49,7 @@ CATALOG(pg_statistic,2619) BKI_WITHOUT_OIDS
|
||||
float4 stanullfrac;
|
||||
|
||||
/*
|
||||
* stawidth is the average width in bytes of non-null entries. For
|
||||
* stawidth is the average width in bytes of non-null entries. For
|
||||
* fixed-width datatypes this is of course the same as the typlen, but for
|
||||
* var-width types it is more useful. Note that this is the average width
|
||||
* of the data as actually stored, post-TOASTing (eg, for a
|
||||
@@ -69,7 +69,7 @@ CATALOG(pg_statistic,2619) BKI_WITHOUT_OIDS
|
||||
* The special negative case allows us to cope with columns that are
|
||||
* unique (stadistinct = -1) or nearly so (for example, a column in
|
||||
* which values appear about twice on the average could be represented
|
||||
* by stadistinct = -0.5). Because the number-of-rows statistic in
|
||||
* by stadistinct = -0.5). Because the number-of-rows statistic in
|
||||
* pg_class may be updated more frequently than pg_statistic is, it's
|
||||
* important to be able to describe such situations as a multiple of
|
||||
* the number of rows, rather than a fixed number of distinct values.
|
||||
@@ -81,8 +81,8 @@ CATALOG(pg_statistic,2619) BKI_WITHOUT_OIDS
|
||||
/* ----------------
|
||||
* To allow keeping statistics on different kinds of datatypes,
|
||||
* we do not hard-wire any particular meaning for the remaining
|
||||
* statistical fields. Instead, we provide several "slots" in which
|
||||
* statistical data can be placed. Each slot includes:
|
||||
* statistical fields. Instead, we provide several "slots" in which
|
||||
* statistical data can be placed. Each slot includes:
|
||||
* kind integer code identifying kind of data
|
||||
* op OID of associated operator, if needed
|
||||
* numbers float4 array (for statistical values)
|
||||
@@ -169,15 +169,15 @@ typedef FormData_pg_statistic *Form_pg_statistic;
|
||||
|
||||
/*
|
||||
* Currently, three statistical slot "kinds" are defined: most common values,
|
||||
* histogram, and correlation. Additional "kinds" will probably appear in
|
||||
* histogram, and correlation. Additional "kinds" will probably appear in
|
||||
* future to help cope with non-scalar datatypes. Also, custom data types
|
||||
* can define their own "kind" codes by mutual agreement between a custom
|
||||
* typanalyze routine and the selectivity estimation functions of the type's
|
||||
* operators.
|
||||
*
|
||||
* Code reading the pg_statistic relation should not assume that a particular
|
||||
* data "kind" will appear in any particular slot. Instead, search the
|
||||
* stakind fields to see if the desired data is available. (The standard
|
||||
* data "kind" will appear in any particular slot. Instead, search the
|
||||
* stakind fields to see if the desired data is available. (The standard
|
||||
* function get_attstatsslot() may be used for this.)
|
||||
*/
|
||||
|
||||
@@ -204,7 +204,7 @@ typedef FormData_pg_statistic *Form_pg_statistic;
|
||||
* the K most common non-null values appearing in the column, and stanumbers
|
||||
* contains their frequencies (fractions of total row count). The values
|
||||
* shall be ordered in decreasing frequency. Note that since the arrays are
|
||||
* variable-size, K may be chosen by the statistics collector. Values should
|
||||
* variable-size, K may be chosen by the statistics collector. Values should
|
||||
* not appear in MCV unless they have been observed to occur more than once;
|
||||
* a unique column will have no MCV slot.
|
||||
*/
|
||||
@@ -216,13 +216,13 @@ typedef FormData_pg_statistic *Form_pg_statistic;
|
||||
* more than one histogram could appear, if a datatype has more than one
|
||||
* useful sort operator.) stavalues contains M (>=2) non-null values that
|
||||
* divide the non-null column data values into M-1 bins of approximately equal
|
||||
* population. The first stavalues item is the MIN and the last is the MAX.
|
||||
* population. The first stavalues item is the MIN and the last is the MAX.
|
||||
* stanumbers is not used and should be NULL. IMPORTANT POINT: if an MCV
|
||||
* slot is also provided, then the histogram describes the data distribution
|
||||
* *after removing the values listed in MCV* (thus, it's a "compressed
|
||||
* histogram" in the technical parlance). This allows a more accurate
|
||||
* representation of the distribution of a column with some very-common
|
||||
* values. In a column with only a few distinct values, it's possible that
|
||||
* values. In a column with only a few distinct values, it's possible that
|
||||
* the MCV list describes the entire data population; in this case the
|
||||
* histogram reduces to empty and should be omitted.
|
||||
*/
|
||||
@@ -233,7 +233,7 @@ typedef FormData_pg_statistic *Form_pg_statistic;
|
||||
* of table tuples and the ordering of data values of this column, as seen
|
||||
* by the "<" operator identified by staop. (As with the histogram, more
|
||||
* than one entry could theoretically appear.) stavalues is not used and
|
||||
* should be NULL. stanumbers contains a single entry, the correlation
|
||||
* should be NULL. stanumbers contains a single entry, the correlation
|
||||
* coefficient between the sequence of data values and the sequence of
|
||||
* their actual tuple positions. The coefficient ranges from +1 to -1.
|
||||
*/
|
||||
@@ -242,7 +242,7 @@ typedef FormData_pg_statistic *Form_pg_statistic;
|
||||
/*
|
||||
* A "most common elements" slot is similar to a "most common values" slot,
|
||||
* except that it stores the most common non-null *elements* of the column
|
||||
* values. This is useful when the column datatype is an array or some other
|
||||
* values. This is useful when the column datatype is an array or some other
|
||||
* type with identifiable elements (for instance, tsvector). staop contains
|
||||
* the equality operator appropriate to the element type. stavalues contains
|
||||
* the most common element values, and stanumbers their frequencies. Unlike
|
||||
|
@@ -22,7 +22,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_trigger definition. cpp turns this into
|
||||
* pg_trigger definition. cpp turns this into
|
||||
* typedef struct FormData_pg_trigger
|
||||
*
|
||||
* Note: when tgconstraint is nonzero, tgconstrrelid, tgconstrindid,
|
||||
|
@@ -24,7 +24,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_ts_dict definition. cpp turns this into
|
||||
* pg_ts_dict definition. cpp turns this into
|
||||
* typedef struct FormData_pg_ts_dict
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -24,7 +24,7 @@
|
||||
#include "catalog/genbki.h"
|
||||
|
||||
/* ----------------
|
||||
* pg_ts_template definition. cpp turns this into
|
||||
* pg_ts_template definition. cpp turns this into
|
||||
* typedef struct FormData_pg_ts_template
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -42,7 +42,7 @@ CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
|
||||
|
||||
/*
|
||||
* For a fixed-size type, typlen is the number of bytes we use to
|
||||
* represent a value of this type, e.g. 4 for an int4. But for a
|
||||
* represent a value of this type, e.g. 4 for an int4. But for a
|
||||
* variable-length type, typlen is negative. We use -1 to indicate a
|
||||
* "varlena" type (one that has a length word), -2 to indicate a
|
||||
* null-terminated C string.
|
||||
@@ -51,7 +51,7 @@ CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
|
||||
|
||||
/*
|
||||
* typbyval determines whether internal Postgres routines pass a value of
|
||||
* this type by value or by reference. typbyval had better be FALSE if
|
||||
* this type by value or by reference. typbyval had better be FALSE if
|
||||
* the length is not 1, 2, or 4 (or 8 on 8-byte-Datum machines).
|
||||
* Variable-length types are always passed by reference. Note that
|
||||
* typbyval can be false even if the length would allow pass-by-value;
|
||||
@@ -71,7 +71,7 @@ CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
|
||||
/*
|
||||
* typcategory and typispreferred help the parser distinguish preferred
|
||||
* and non-preferred coercions. The category can be any single ASCII
|
||||
* character (but not \0). The categories used for built-in types are
|
||||
* character (but not \0). The categories used for built-in types are
|
||||
* identified by the TYPCATEGORY macros below.
|
||||
*/
|
||||
char typcategory; /* arbitrary type classification */
|
||||
@@ -80,7 +80,7 @@ CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
|
||||
|
||||
/*
|
||||
* If typisdefined is false, the entry is only a placeholder (forward
|
||||
* reference). We know the type name, but not yet anything else about it.
|
||||
* reference). We know the type name, but not yet anything else about it.
|
||||
*/
|
||||
bool typisdefined;
|
||||
|
||||
@@ -141,7 +141,7 @@ CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
|
||||
* 'd' = DOUBLE alignment (8 bytes on many machines, but by no means all).
|
||||
*
|
||||
* See include/access/tupmacs.h for the macros that compute these
|
||||
* alignment requirements. Note also that we allow the nominal alignment
|
||||
* alignment requirements. Note also that we allow the nominal alignment
|
||||
* to be violated when storing "packed" varlenas; the TOAST mechanism
|
||||
* takes care of hiding that from most code.
|
||||
*
|
||||
@@ -176,7 +176,7 @@ CATALOG(pg_type,1247) BKI_BOOTSTRAP BKI_ROWTYPE_OID(71) BKI_SCHEMA_MACRO
|
||||
|
||||
/*
|
||||
* Domains use typbasetype to show the base (or domain) type that the
|
||||
* domain is based on. Zero if the type is not a domain.
|
||||
* domain is based on. Zero if the type is not a domain.
|
||||
*/
|
||||
Oid typbasetype;
|
||||
|
||||
|
@@ -24,7 +24,7 @@
|
||||
* related routines. CommentObject() implements the SQL "COMMENT ON"
|
||||
* command. DeleteComments() deletes all comments for an object.
|
||||
* CreateComments creates (or deletes, if comment is NULL) a comment
|
||||
* for a specific key. There are versions of these two methods for
|
||||
* for a specific key. There are versions of these two methods for
|
||||
* both normal and shared objects.
|
||||
*------------------------------------------------------------------
|
||||
*/
|
||||
|
@@ -25,12 +25,12 @@
|
||||
|
||||
/*----------
|
||||
* ANALYZE builds one of these structs for each attribute (column) that is
|
||||
* to be analyzed. The struct and subsidiary data are in anl_context,
|
||||
* to be analyzed. The struct and subsidiary data are in anl_context,
|
||||
* so they live until the end of the ANALYZE operation.
|
||||
*
|
||||
* The type-specific typanalyze function is passed a pointer to this struct
|
||||
* and must return TRUE to continue analysis, FALSE to skip analysis of this
|
||||
* column. In the TRUE case it must set the compute_stats and minrows fields,
|
||||
* column. In the TRUE case it must set the compute_stats and minrows fields,
|
||||
* and can optionally set extra_data to pass additional info to compute_stats.
|
||||
* minrows is its request for the minimum number of sample rows to be gathered
|
||||
* (but note this request might not be honored, eg if there are fewer rows
|
||||
@@ -68,7 +68,7 @@ typedef struct VacAttrStats
|
||||
* type-specific typanalyze function.
|
||||
*
|
||||
* Note: do not assume that the data being analyzed has the same datatype
|
||||
* shown in attr, ie do not trust attr->atttypid, attlen, etc. This is
|
||||
* shown in attr, ie do not trust attr->atttypid, attlen, etc. This is
|
||||
* because some index opclasses store a different type than the underlying
|
||||
* column/expression. Instead use attrtypid, attrtypmod, and attrtype for
|
||||
* information about the datatype being fed to the typanalyze function.
|
||||
|
@@ -36,7 +36,7 @@
|
||||
* REWIND indicates that the plan node should try to efficiently support
|
||||
* rescans without parameter changes. (Nodes must support ExecReScan calls
|
||||
* in any case, but if this flag was not given, they are at liberty to do it
|
||||
* through complete recalculation. Note that a parameter change forces a
|
||||
* through complete recalculation. Note that a parameter change forces a
|
||||
* full recalculation in any case.)
|
||||
*
|
||||
* BACKWARD indicates that the plan node must respect the es_direction flag.
|
||||
|
@@ -42,7 +42,7 @@
|
||||
* If nbatch > 1 then tuples that don't belong in first batch get saved
|
||||
* into inner-batch temp files. The same statements apply for the
|
||||
* first scan of the outer relation, except we write tuples to outer-batch
|
||||
* temp files. After finishing the first scan, we do the following for
|
||||
* temp files. After finishing the first scan, we do the following for
|
||||
* each remaining batch:
|
||||
* 1. Read tuples from inner batch file, load into hash buckets.
|
||||
* 2. Read tuples from outer batch file, match to hash buckets and output.
|
||||
@@ -133,7 +133,7 @@ typedef struct HashJoinTableData
|
||||
|
||||
/*
|
||||
* These arrays are allocated for the life of the hash join, but only if
|
||||
* nbatch > 1. A file is opened only when we first write a tuple into it
|
||||
* nbatch > 1. A file is opened only when we first write a tuple into it
|
||||
* (otherwise its pointer remains NULL). Note that the zero'th array
|
||||
* elements never get used, since we will process rather than dump out any
|
||||
* tuples of batch zero.
|
||||
|
@@ -43,7 +43,7 @@ typedef struct
|
||||
* For a saved plan, the _SPI_plan struct and the argument type array are in
|
||||
* the plancxt (which can be really small). All the other subsidiary state
|
||||
* is in plancache entries identified by plancache_list (note: the list cells
|
||||
* themselves are in plancxt). We rely on plancache.c to keep the cache
|
||||
* themselves are in plancxt). We rely on plancache.c to keep the cache
|
||||
* entries up-to-date as needed. The plancxt is a child of CacheMemoryContext
|
||||
* since it should persist until explicitly destroyed.
|
||||
*
|
||||
|
@@ -34,7 +34,7 @@
|
||||
*
|
||||
* A "minimal" tuple is handled similarly to a palloc'd regular tuple.
|
||||
* At present, minimal tuples never are stored in buffers, so there is no
|
||||
* parallel to case 1. Note that a minimal tuple has no "system columns".
|
||||
* parallel to case 1. Note that a minimal tuple has no "system columns".
|
||||
* (Actually, it could have an OID, but we have no need to access the OID.)
|
||||
*
|
||||
* A "virtual" tuple is an optimization used to minimize physical data
|
||||
@@ -44,7 +44,7 @@
|
||||
* a lower plan node's output TupleTableSlot, or to a function result
|
||||
* constructed in a plan node's per-tuple econtext. It is the responsibility
|
||||
* of the generating plan node to be sure these resources are not released
|
||||
* for as long as the virtual tuple needs to be valid. We only use virtual
|
||||
* for as long as the virtual tuple needs to be valid. We only use virtual
|
||||
* tuples in the result slots of plan nodes --- tuples to be copied anywhere
|
||||
* else need to be "materialized" into physical tuples. Note also that a
|
||||
* virtual tuple does not have any "system columns".
|
||||
@@ -58,11 +58,11 @@
|
||||
* payloads when this is the case.
|
||||
*
|
||||
* The Datum/isnull arrays of a TupleTableSlot serve double duty. When the
|
||||
* slot contains a virtual tuple, they are the authoritative data. When the
|
||||
* slot contains a virtual tuple, they are the authoritative data. When the
|
||||
* slot contains a physical tuple, the arrays contain data extracted from
|
||||
* the tuple. (In this state, any pass-by-reference Datums point into
|
||||
* the physical tuple.) The extracted information is built "lazily",
|
||||
* ie, only as needed. This serves to avoid repeated extraction of data
|
||||
* ie, only as needed. This serves to avoid repeated extraction of data
|
||||
* from the physical tuple.
|
||||
*
|
||||
* A TupleTableSlot can also be "empty", holding no valid data. This is
|
||||
@@ -89,7 +89,7 @@
|
||||
* buffer page.)
|
||||
*
|
||||
* tts_nvalid indicates the number of valid columns in the tts_values/isnull
|
||||
* arrays. When the slot is holding a "virtual" tuple this must be equal
|
||||
* arrays. When the slot is holding a "virtual" tuple this must be equal
|
||||
* to the descriptor's natts. When the slot is holding a physical tuple
|
||||
* this is equal to the number of columns we have extracted (we always
|
||||
* extract columns from left to right, so there are no holes).
|
||||
@@ -103,7 +103,7 @@
|
||||
* has only a minimal and not also a regular physical tuple, then tts_tuple
|
||||
* points at tts_minhdr and the fields of that struct are set correctly
|
||||
* for access to the minimal tuple; in particular, tts_minhdr.t_data points
|
||||
* MINIMAL_TUPLE_OFFSET bytes before tts_mintuple. This allows column
|
||||
* MINIMAL_TUPLE_OFFSET bytes before tts_mintuple. This allows column
|
||||
* extraction to treat the case identically to regular physical tuples.
|
||||
*
|
||||
* tts_slow/tts_off are saved state for slot_deform_tuple, and should not
|
||||
|
@@ -101,7 +101,7 @@ extern void fmgr_info_copy(FmgrInfo *dstinfo, FmgrInfo *srcinfo,
|
||||
|
||||
/*
|
||||
* This macro initializes all the fields of a FunctionCallInfoData except
|
||||
* for the arg[] and argnull[] arrays. Performance testing has shown that
|
||||
* for the arg[] and argnull[] arrays. Performance testing has shown that
|
||||
* the fastest way to set up argnull[] for small numbers of arguments is to
|
||||
* explicitly set each required element to false, so we don't try to zero
|
||||
* out the argnull[] array in the macro.
|
||||
@@ -118,7 +118,7 @@ extern void fmgr_info_copy(FmgrInfo *dstinfo, FmgrInfo *srcinfo,
|
||||
|
||||
/*
|
||||
* This macro invokes a function given a filled-in FunctionCallInfoData
|
||||
* struct. The macro result is the returned Datum --- but note that
|
||||
* struct. The macro result is the returned Datum --- but note that
|
||||
* caller must still check fcinfo->isnull! Also, if function is strict,
|
||||
* it is caller's responsibility to verify that no null arguments are present
|
||||
* before calling.
|
||||
@@ -167,11 +167,11 @@ extern void fmgr_info_copy(FmgrInfo *dstinfo, FmgrInfo *srcinfo,
|
||||
* which are varlena types). pg_detoast_datum() gives you either the input
|
||||
* datum (if not toasted) or a detoasted copy allocated with palloc().
|
||||
* pg_detoast_datum_copy() always gives you a palloc'd copy --- use it
|
||||
* if you need a modifiable copy of the input. Caller is expected to have
|
||||
* if you need a modifiable copy of the input. Caller is expected to have
|
||||
* checked for null inputs first, if necessary.
|
||||
*
|
||||
* pg_detoast_datum_packed() will return packed (1-byte header) datums
|
||||
* unmodified. It will still expand an externally toasted or compressed datum.
|
||||
* unmodified. It will still expand an externally toasted or compressed datum.
|
||||
* The resulting datum can be accessed using VARSIZE_ANY() and VARDATA_ANY()
|
||||
* (beware of multiple evaluations in those macros!)
|
||||
*
|
||||
@@ -202,7 +202,7 @@ extern struct varlena *pg_detoast_datum_packed(struct varlena * datum);
|
||||
pg_detoast_datum_packed((struct varlena *) DatumGetPointer(datum))
|
||||
|
||||
/*
|
||||
* Support for cleaning up detoasted copies of inputs. This must only
|
||||
* Support for cleaning up detoasted copies of inputs. This must only
|
||||
* be used for pass-by-ref datatypes, and normally would only be used
|
||||
* for toastable types. If the given pointer is different from the
|
||||
* original argument, assume it's a palloc'd detoasted copy, and pfree it.
|
||||
@@ -319,7 +319,7 @@ extern struct varlena *pg_detoast_datum_packed(struct varlena * datum);
|
||||
* Dynamically loaded functions may use either the version-1 ("new style")
|
||||
* or version-0 ("old style") calling convention. Version 1 is the call
|
||||
* convention defined in this header file; version 0 is the old "plain C"
|
||||
* convention. A version-1 function must be accompanied by the macro call
|
||||
* convention. A version-1 function must be accompanied by the macro call
|
||||
*
|
||||
* PG_FUNCTION_INFO_V1(function_name);
|
||||
*
|
||||
@@ -500,8 +500,8 @@ extern Datum FunctionCall9Coll(FmgrInfo *flinfo, Oid collation,
|
||||
|
||||
/* These are for invocation of a function identified by OID with a
|
||||
* directly-computed parameter list. Note that neither arguments nor result
|
||||
* are allowed to be NULL. These are essentially FunctionLookup() followed
|
||||
* by FunctionCallN(). If the same function is to be invoked repeatedly,
|
||||
* are allowed to be NULL. These are essentially FunctionLookup() followed
|
||||
* by FunctionCallN(). If the same function is to be invoked repeatedly,
|
||||
* do the FunctionLookup() once and then use FunctionCallN().
|
||||
*/
|
||||
extern Datum OidFunctionCall0Coll(Oid functionId, Oid collation);
|
||||
@@ -655,7 +655,7 @@ extern int AggCheckCallContext(FunctionCallInfo fcinfo,
|
||||
* We allow plugin modules to hook function entry/exit. This is intended
|
||||
* as support for loadable security policy modules, which may want to
|
||||
* perform additional privilege checks on function entry or exit, or to do
|
||||
* other internal bookkeeping. To make this possible, such modules must be
|
||||
* other internal bookkeeping. To make this possible, such modules must be
|
||||
* able not only to support normal function entry and exit, but also to trap
|
||||
* the case where we bail out due to an error; and they must also be able to
|
||||
* prevent inlining.
|
||||
|
@@ -129,7 +129,7 @@ typedef struct FuncCallContext
|
||||
* Given a function's call info record, determine the kind of datatype
|
||||
* it is supposed to return. If resultTypeId isn't NULL, *resultTypeId
|
||||
* receives the actual datatype OID (this is mainly useful for scalar
|
||||
* result types). If resultTupleDesc isn't NULL, *resultTupleDesc
|
||||
* result types). If resultTupleDesc isn't NULL, *resultTupleDesc
|
||||
* receives a pointer to a TupleDesc when the result is of a composite
|
||||
* type, or NULL when it's a scalar result or the rowtype could not be
|
||||
* determined. NB: the tupledesc should be copied if it is to be
|
||||
|
@@ -60,7 +60,7 @@ typedef StringInfoData *StringInfo;
|
||||
*
|
||||
* NOTE: some routines build up a string using StringInfo, and then
|
||||
* release the StringInfoData but return the data string itself to their
|
||||
* caller. At that point the data string looks like a plain palloc'd
|
||||
* caller. At that point the data string looks like a plain palloc'd
|
||||
* string.
|
||||
*-------------------------
|
||||
*/
|
||||
@@ -100,7 +100,7 @@ __attribute__((format(PG_PRINTF_ATTRIBUTE, 2, 3)));
|
||||
/*------------------------
|
||||
* appendStringInfoVA
|
||||
* Attempt to format text data under the control of fmt (an sprintf-style
|
||||
* format string) and append it to whatever is already in str. If successful
|
||||
* format string) and append it to whatever is already in str. If successful
|
||||
* return true; if not (because there's not enough space), return false
|
||||
* without modifying str. Typically the caller would enlarge str and retry
|
||||
* on false return --- see appendStringInfo for standard usage pattern.
|
||||
|
@@ -93,10 +93,10 @@ typedef struct
|
||||
#endif
|
||||
|
||||
/*
|
||||
* This is used by the postmaster in its communication with frontends. It
|
||||
* This is used by the postmaster in its communication with frontends. It
|
||||
* contains all state information needed during this communication before the
|
||||
* backend is run. The Port structure is kept in malloc'd memory and is
|
||||
* still available when a backend is running (see MyProcPort). The data
|
||||
* backend is run. The Port structure is kept in malloc'd memory and is
|
||||
* still available when a backend is running (see MyProcPort). The data
|
||||
* it points to must also be malloc'd, or else palloc'd in TopMemoryContext,
|
||||
* so that it survives into PostgresMain execution!
|
||||
*
|
||||
@@ -131,7 +131,7 @@ typedef struct Port
|
||||
|
||||
/*
|
||||
* Information that needs to be saved from the startup packet and passed
|
||||
* into backend execution. "char *" fields are NULL if not set.
|
||||
* into backend execution. "char *" fields are NULL if not set.
|
||||
* guc_options points to a List of alternating option names and values.
|
||||
*/
|
||||
char *database_name;
|
||||
|
@@ -153,7 +153,7 @@ extern bool Db_user_namespace;
|
||||
|
||||
/*
|
||||
* In protocol 3.0 and later, the startup packet length is not fixed, but
|
||||
* we set an arbitrary limit on it anyway. This is just to prevent simple
|
||||
* we set an arbitrary limit on it anyway. This is just to prevent simple
|
||||
* denial-of-service attacks via sending enough data to run the server
|
||||
* out of memory.
|
||||
*/
|
||||
|
@@ -10,7 +10,7 @@
|
||||
*
|
||||
* NOTES
|
||||
* This is used both by the backend and by libpq, but should not be
|
||||
* included by libpq client programs. In particular, a libpq client
|
||||
* included by libpq client programs. In particular, a libpq client
|
||||
* should not assume that the encoding IDs used by the version of libpq
|
||||
* it's linked to match up with the IDs declared here.
|
||||
*
|
||||
@@ -38,7 +38,7 @@ typedef unsigned int pg_wchar;
|
||||
|
||||
/*
|
||||
* Leading byte types or leading prefix byte for MULE internal code.
|
||||
* See http://www.xemacs.org for more details. (there is a doc titled
|
||||
* See http://www.xemacs.org for more details. (there is a doc titled
|
||||
* "XEmacs Internals Manual", "MULE Character Sets and Encodings"
|
||||
* section.)
|
||||
*/
|
||||
|
@@ -37,7 +37,7 @@
|
||||
* In both cases, we need to be able to clean up the current transaction
|
||||
* gracefully, so we can't respond to the interrupt instantaneously ---
|
||||
* there's no guarantee that internal data structures would be self-consistent
|
||||
* if the code is interrupted at an arbitrary instant. Instead, the signal
|
||||
* if the code is interrupted at an arbitrary instant. Instead, the signal
|
||||
* handlers set flags that are checked periodically during execution.
|
||||
*
|
||||
* The CHECK_FOR_INTERRUPTS() macro is called at strategically located spots
|
||||
@@ -46,19 +46,19 @@
|
||||
* might sometimes be called in contexts that do *not* want to allow a cancel
|
||||
* or die interrupt. The HOLD_INTERRUPTS() and RESUME_INTERRUPTS() macros
|
||||
* allow code to ensure that no cancel or die interrupt will be accepted,
|
||||
* even if CHECK_FOR_INTERRUPTS() gets called in a subroutine. The interrupt
|
||||
* even if CHECK_FOR_INTERRUPTS() gets called in a subroutine. The interrupt
|
||||
* will be held off until CHECK_FOR_INTERRUPTS() is done outside any
|
||||
* HOLD_INTERRUPTS() ... RESUME_INTERRUPTS() section.
|
||||
*
|
||||
* Special mechanisms are used to let an interrupt be accepted when we are
|
||||
* waiting for a lock or when we are waiting for command input (but, of
|
||||
* course, only if the interrupt holdoff counter is zero). See the
|
||||
* course, only if the interrupt holdoff counter is zero). See the
|
||||
* related code for details.
|
||||
*
|
||||
* A related, but conceptually distinct, mechanism is the "critical section"
|
||||
* mechanism. A critical section not only holds off cancel/die interrupts,
|
||||
* but causes any ereport(ERROR) or ereport(FATAL) to become ereport(PANIC)
|
||||
* --- that is, a system-wide reset is forced. Needless to say, only really
|
||||
* --- that is, a system-wide reset is forced. Needless to say, only really
|
||||
* *critical* code should be marked as a critical section! Currently, this
|
||||
* mechanism is only used for XLOG-related code.
|
||||
*
|
||||
@@ -260,7 +260,7 @@ extern int trace_recovery(int trace_level);
|
||||
|
||||
/*****************************************************************************
|
||||
* pdir.h -- *
|
||||
* POSTGRES directory path definitions. *
|
||||
* POSTGRES directory path definitions. *
|
||||
*****************************************************************************/
|
||||
|
||||
/* flags to be OR'd to form sec_context */
|
||||
@@ -299,7 +299,7 @@ extern bool superuser_arg(Oid roleid); /* given user is superuser */
|
||||
|
||||
/*****************************************************************************
|
||||
* pmod.h -- *
|
||||
* POSTGRES processing mode definitions. *
|
||||
* POSTGRES processing mode definitions. *
|
||||
*****************************************************************************/
|
||||
|
||||
/*
|
||||
@@ -314,7 +314,7 @@ extern bool superuser_arg(Oid roleid); /* given user is superuser */
|
||||
* is used during the initial generation of template databases.
|
||||
*
|
||||
* Initialization mode: used while starting a backend, until all normal
|
||||
* initialization is complete. Some code behaves differently when executed
|
||||
* initialization is complete. Some code behaves differently when executed
|
||||
* in this mode to enable system bootstrapping.
|
||||
*
|
||||
* If a POSTGRES binary is in normal mode, then all code may be executed
|
||||
@@ -347,7 +347,7 @@ extern ProcessingMode Mode;
|
||||
|
||||
/*****************************************************************************
|
||||
* pinit.h -- *
|
||||
* POSTGRES initialization and cleanup definitions. *
|
||||
* POSTGRES initialization and cleanup definitions. *
|
||||
*****************************************************************************/
|
||||
|
||||
/* in utils/init/postinit.c */
|
||||
|
@@ -90,14 +90,14 @@ typedef struct ExprContext_CB
|
||||
*
|
||||
* This class holds the "current context" information
|
||||
* needed to evaluate expressions for doing tuple qualifications
|
||||
* and tuple projections. For example, if an expression refers
|
||||
* and tuple projections. For example, if an expression refers
|
||||
* to an attribute in the current inner tuple then we need to know
|
||||
* what the current inner tuple is and so we look at the expression
|
||||
* context.
|
||||
*
|
||||
* There are two memory contexts associated with an ExprContext:
|
||||
* * ecxt_per_query_memory is a query-lifespan context, typically the same
|
||||
* context the ExprContext node itself is allocated in. This context
|
||||
* context the ExprContext node itself is allocated in. This context
|
||||
* can be used for purposes such as storing function call cache info.
|
||||
* * ecxt_per_tuple_memory is a short-term context for expression results.
|
||||
* As the name suggests, it will typically be reset once per tuple,
|
||||
@@ -200,9 +200,9 @@ typedef struct ReturnSetInfo
|
||||
* Nodes which need to do projections create one of these.
|
||||
*
|
||||
* ExecProject() evaluates the tlist, forms a tuple, and stores it
|
||||
* in the given slot. Note that the result will be a "virtual" tuple
|
||||
* in the given slot. Note that the result will be a "virtual" tuple
|
||||
* unless ExecMaterializeSlot() is then called to force it to be
|
||||
* converted to a physical tuple. The slot must have a tupledesc
|
||||
* converted to a physical tuple. The slot must have a tupledesc
|
||||
* that matches the output of the tlist!
|
||||
*
|
||||
* The planner very often produces tlists that consist entirely of
|
||||
@@ -257,7 +257,7 @@ typedef struct ProjectionInfo
|
||||
* in emitted tuples. For example, when we do an UPDATE query,
|
||||
* the planner adds a "junk" entry to the targetlist so that the tuples
|
||||
* returned to ExecutePlan() contain an extra attribute: the ctid of
|
||||
* the tuple to be updated. This is needed to do the update, but we
|
||||
* the tuple to be updated. This is needed to do the update, but we
|
||||
* don't want the ctid to be part of the stored new tuple! So, we
|
||||
* apply a "junk filter" to remove the junk attributes and form the
|
||||
* real output tuple. The junkfilter code also provides routines to
|
||||
@@ -391,7 +391,7 @@ typedef struct EState
|
||||
|
||||
/*
|
||||
* These fields are for re-evaluating plan quals when an updated tuple is
|
||||
* substituted in READ COMMITTED mode. es_epqTuple[] contains tuples that
|
||||
* substituted in READ COMMITTED mode. es_epqTuple[] contains tuples that
|
||||
* scan plan nodes should return instead of whatever they'd normally
|
||||
* return, or NULL if nothing to return; es_epqTupleSet[] is true if a
|
||||
* particular array entry is valid; and es_epqScanDone[] is state to
|
||||
@@ -653,7 +653,7 @@ typedef struct FuncExprState
|
||||
|
||||
/*
|
||||
* In some cases we need to compute a tuple descriptor for the function's
|
||||
* output. If so, it's stored here.
|
||||
* output. If so, it's stored here.
|
||||
*/
|
||||
TupleDesc funcResultDesc;
|
||||
bool funcReturnsTuple; /* valid when funcResultDesc isn't
|
||||
@@ -677,7 +677,7 @@ typedef struct FuncExprState
|
||||
|
||||
/*
|
||||
* Flag to remember whether we have registered a shutdown callback for
|
||||
* this FuncExprState. We do so only if funcResultStore or setArgsValid
|
||||
* this FuncExprState. We do so only if funcResultStore or setArgsValid
|
||||
* has been set at least once (since all the callback is for is to release
|
||||
* the tuplestore or clear setArgsValid).
|
||||
*/
|
||||
@@ -1419,7 +1419,7 @@ typedef struct CteScanState
|
||||
* WorkTableScanState information
|
||||
*
|
||||
* WorkTableScan nodes are used to scan the work table created by
|
||||
* a RecursiveUnion node. We locate the RecursiveUnion node
|
||||
* a RecursiveUnion node. We locate the RecursiveUnion node
|
||||
* during executor startup.
|
||||
* ----------------
|
||||
*/
|
||||
@@ -1731,7 +1731,7 @@ typedef struct WindowAggState
|
||||
* UniqueState information
|
||||
*
|
||||
* Unique nodes are used "on top of" sort nodes to discard
|
||||
* duplicate tuples returned from the sort phase. Basically
|
||||
* duplicate tuples returned from the sort phase. Basically
|
||||
* all it does is compare the current tuple from the subplan
|
||||
* with the previously fetched tuple (stored in its result slot).
|
||||
* If the two are identical in all interesting fields, then
|
||||
|
@@ -567,7 +567,7 @@ typedef enum JoinType
|
||||
/*
|
||||
* Semijoins and anti-semijoins (as defined in relational theory) do not
|
||||
* appear in the SQL JOIN syntax, but there are standard idioms for
|
||||
* representing them (e.g., using EXISTS). The planner recognizes these
|
||||
* representing them (e.g., using EXISTS). The planner recognizes these
|
||||
* cases and converts them to joins. So the planner and executor must
|
||||
* support these codes. NOTE: in JOIN_SEMI output, it is unspecified
|
||||
* which matching RHS row is joined to. In JOIN_ANTI output, the row is
|
||||
@@ -591,7 +591,7 @@ typedef enum JoinType
|
||||
/*
|
||||
* OUTER joins are those for which pushed-down quals must behave differently
|
||||
* from the join's own quals. This is in fact everything except INNER and
|
||||
* SEMI joins. However, this macro must also exclude the JOIN_UNIQUE symbols
|
||||
* SEMI joins. However, this macro must also exclude the JOIN_UNIQUE symbols
|
||||
* since those are temporary proxies for what will eventually be an INNER
|
||||
* join.
|
||||
*
|
||||
|
@@ -22,20 +22,20 @@ struct ParseState;
|
||||
* ParamListInfo
|
||||
*
|
||||
* ParamListInfo arrays are used to pass parameters into the executor
|
||||
* for parameterized plans. Each entry in the array defines the value
|
||||
* for parameterized plans. Each entry in the array defines the value
|
||||
* to be substituted for a PARAM_EXTERN parameter. The "paramid"
|
||||
* of a PARAM_EXTERN Param can range from 1 to numParams.
|
||||
*
|
||||
* Although parameter numbers are normally consecutive, we allow
|
||||
* ptype == InvalidOid to signal an unused array entry.
|
||||
*
|
||||
* pflags is a flags field. Currently the only used bit is:
|
||||
* pflags is a flags field. Currently the only used bit is:
|
||||
* PARAM_FLAG_CONST signals the planner that it may treat this parameter
|
||||
* as a constant (i.e., generate a plan that works only for this value
|
||||
* of the parameter).
|
||||
*
|
||||
* There are two hook functions that can be associated with a ParamListInfo
|
||||
* array to support dynamic parameter handling. First, if paramFetch
|
||||
* array to support dynamic parameter handling. First, if paramFetch
|
||||
* isn't null and the executor requires a value for an invalid parameter
|
||||
* (one with ptype == InvalidOid), the paramFetch hook is called to give
|
||||
* it a chance to fill in the parameter value. Second, a parserSetup
|
||||
@@ -85,7 +85,7 @@ typedef struct ParamListInfoData
|
||||
* es_param_exec_vals or ecxt_param_exec_vals.
|
||||
*
|
||||
* If execPlan is not NULL, it points to a SubPlanState node that needs
|
||||
* to be executed to produce the value. (This is done so that we can have
|
||||
* to be executed to produce the value. (This is done so that we can have
|
||||
* lazy evaluation of InitPlans: they aren't executed until/unless a
|
||||
* result value is needed.) Otherwise the value is assumed to be valid
|
||||
* when needed.
|
||||
|
@@ -157,7 +157,7 @@ typedef struct Query
|
||||
* Supporting data structures for Parse Trees
|
||||
*
|
||||
* Most of these node types appear in raw parsetrees output by the grammar,
|
||||
* and get transformed to something else by the analyzer. A few of them
|
||||
* and get transformed to something else by the analyzer. A few of them
|
||||
* are used as-is in transformed querytrees.
|
||||
****************************************************************************/
|
||||
|
||||
@@ -171,7 +171,7 @@ typedef struct Query
|
||||
* be prespecified in typemod, otherwise typemod is unused.
|
||||
*
|
||||
* If pct_type is TRUE, then names is actually a field name and we look up
|
||||
* the type of that field. Otherwise (the normal case), names is a type
|
||||
* the type of that field. Otherwise (the normal case), names is a type
|
||||
* name possibly qualified with schema and database name.
|
||||
*/
|
||||
typedef struct TypeName
|
||||
@@ -190,7 +190,7 @@ typedef struct TypeName
|
||||
/*
|
||||
* ColumnRef - specifies a reference to a column, or possibly a whole tuple
|
||||
*
|
||||
* The "fields" list must be nonempty. It can contain string Value nodes
|
||||
* The "fields" list must be nonempty. It can contain string Value nodes
|
||||
* (representing names) and A_Star nodes (representing occurrence of a '*').
|
||||
* Currently, A_Star must appear only as the last list element --- the grammar
|
||||
* is responsible for enforcing this!
|
||||
@@ -474,7 +474,7 @@ typedef struct RangeFunction
|
||||
* in either "raw" form (an untransformed parse tree) or "cooked" form
|
||||
* (a post-parse-analysis, executable expression tree), depending on
|
||||
* how this ColumnDef node was created (by parsing, or by inheritance
|
||||
* from an existing relation). We should never have both in the same node!
|
||||
* from an existing relation). We should never have both in the same node!
|
||||
*
|
||||
* Similarly, we may have a COLLATE specification in either raw form
|
||||
* (represented as a CollateClause with arg==NULL) or cooked form
|
||||
@@ -544,7 +544,7 @@ typedef struct IndexElem
|
||||
/*
|
||||
* DefElem - a generic "name = value" option definition
|
||||
*
|
||||
* In some contexts the name can be qualified. Also, certain SQL commands
|
||||
* In some contexts the name can be qualified. Also, certain SQL commands
|
||||
* allow a SET/ADD/DROP action to be attached to option settings, so it's
|
||||
* convenient to carry a field for that too. (Note: currently, it is our
|
||||
* practice that the grammar allows namespace and action only in statements
|
||||
@@ -571,7 +571,7 @@ typedef struct DefElem
|
||||
/*
|
||||
* LockingClause - raw representation of FOR UPDATE/SHARE options
|
||||
*
|
||||
* Note: lockedRels == NIL means "all relations in query". Otherwise it
|
||||
* Note: lockedRels == NIL means "all relations in query". Otherwise it
|
||||
* is a list of RangeVar nodes. (We use RangeVar mainly because it carries
|
||||
* a location field --- currently, parse analysis insists on unqualified
|
||||
* names in LockingClause.)
|
||||
@@ -626,8 +626,8 @@ typedef struct XmlSerialize
|
||||
*
|
||||
* In RELATION RTEs, the colnames in both alias and eref are indexed by
|
||||
* physical attribute number; this means there must be colname entries for
|
||||
* dropped columns. When building an RTE we insert empty strings ("") for
|
||||
* dropped columns. Note however that a stored rule may have nonempty
|
||||
* dropped columns. When building an RTE we insert empty strings ("") for
|
||||
* dropped columns. Note however that a stored rule may have nonempty
|
||||
* colnames for columns dropped since the rule was created (and for that
|
||||
* matter the colnames might be out of date due to column renamings).
|
||||
* The same comments apply to FUNCTION RTEs when the function's return type
|
||||
@@ -635,9 +635,9 @@ typedef struct XmlSerialize
|
||||
*
|
||||
* In JOIN RTEs, the colnames in both alias and eref are one-to-one with
|
||||
* joinaliasvars entries. A JOIN RTE will omit columns of its inputs when
|
||||
* those columns are known to be dropped at parse time. Again, however,
|
||||
* those columns are known to be dropped at parse time. Again, however,
|
||||
* a stored rule might contain entries for columns dropped since the rule
|
||||
* was created. (This is only possible for columns not actually referenced
|
||||
* was created. (This is only possible for columns not actually referenced
|
||||
* in the rule.) When loading a stored rule, we replace the joinaliasvars
|
||||
* items for any such columns with null pointers. (We can't simply delete
|
||||
* them from the joinaliasvars list, because that would affect the attnums
|
||||
@@ -656,7 +656,7 @@ typedef struct XmlSerialize
|
||||
* decompiled queries.
|
||||
*
|
||||
* requiredPerms and checkAsUser specify run-time access permissions
|
||||
* checks to be performed at query startup. The user must have *all*
|
||||
* checks to be performed at query startup. The user must have *all*
|
||||
* of the permissions that are OR'd together in requiredPerms (zero
|
||||
* indicates no permissions checking). If checkAsUser is not zero,
|
||||
* then do the permissions checks using the access rights of that user,
|
||||
@@ -710,7 +710,7 @@ typedef struct RangeTblEntry
|
||||
* Fields valid for a join RTE (else NULL/zero):
|
||||
*
|
||||
* joinaliasvars is a list of (usually) Vars corresponding to the columns
|
||||
* of the join result. An alias Var referencing column K of the join
|
||||
* of the join result. An alias Var referencing column K of the join
|
||||
* result can be replaced by the K'th element of joinaliasvars --- but to
|
||||
* simplify the task of reverse-listing aliases correctly, we do not do
|
||||
* that until planning time. In detail: an element of joinaliasvars can
|
||||
@@ -731,7 +731,7 @@ typedef struct RangeTblEntry
|
||||
*
|
||||
* If the function returns RECORD, funccoltypes lists the column types
|
||||
* declared in the RTE's column type specification, funccoltypmods lists
|
||||
* their declared typmods, funccolcollations their collations. Otherwise,
|
||||
* their declared typmods, funccolcollations their collations. Otherwise,
|
||||
* those fields are NIL.
|
||||
*/
|
||||
Node *funcexpr; /* expression tree for func call */
|
||||
@@ -776,7 +776,7 @@ typedef struct RangeTblEntry
|
||||
* You might think that ORDER BY is only interested in defining ordering,
|
||||
* and GROUP/DISTINCT are only interested in defining equality. However,
|
||||
* one way to implement grouping is to sort and then apply a "uniq"-like
|
||||
* filter. So it's also interesting to keep track of possible sort operators
|
||||
* filter. So it's also interesting to keep track of possible sort operators
|
||||
* for GROUP/DISTINCT, and in particular to try to sort for the grouping
|
||||
* in a way that will also yield a requested ORDER BY ordering. So we need
|
||||
* to be able to compare ORDER BY and GROUP/DISTINCT lists, which motivates
|
||||
@@ -796,15 +796,15 @@ typedef struct RangeTblEntry
|
||||
* here, but it's cheap to get it along with the sortop, and requiring it
|
||||
* to be valid eases comparisons to grouping items.) Note that this isn't
|
||||
* actually enough information to determine an ordering: if the sortop is
|
||||
* collation-sensitive, a collation OID is needed too. We don't store the
|
||||
* collation-sensitive, a collation OID is needed too. We don't store the
|
||||
* collation in SortGroupClause because it's not available at the time the
|
||||
* parser builds the SortGroupClause; instead, consult the exposed collation
|
||||
* of the referenced targetlist expression to find out what it is.
|
||||
*
|
||||
* In a grouping item, eqop must be valid. If the eqop is a btree equality
|
||||
* In a grouping item, eqop must be valid. If the eqop is a btree equality
|
||||
* operator, then sortop should be set to a compatible ordering operator.
|
||||
* We prefer to set eqop/sortop/nulls_first to match any ORDER BY item that
|
||||
* the query presents for the same tlist item. If there is none, we just
|
||||
* the query presents for the same tlist item. If there is none, we just
|
||||
* use the default ordering op for the datatype.
|
||||
*
|
||||
* If the tlist item's type has a hash opclass but no btree opclass, then
|
||||
@@ -1060,7 +1060,7 @@ typedef struct SelectStmt
|
||||
* range table. Its setOperations field shows the tree of set operations,
|
||||
* with leaf SelectStmt nodes replaced by RangeTblRef nodes, and internal
|
||||
* nodes replaced by SetOperationStmt nodes. Information about the output
|
||||
* column types is added, too. (Note that the child nodes do not necessarily
|
||||
* column types is added, too. (Note that the child nodes do not necessarily
|
||||
* produce these types directly, but we've checked that their output types
|
||||
* can be coerced to the output column type.) Also, if it's not UNION ALL,
|
||||
* information about the types' sort/group semantics is provided in the form
|
||||
@@ -1348,7 +1348,7 @@ typedef struct AccessPriv
|
||||
*
|
||||
* Note: because of the parsing ambiguity with the GRANT <privileges>
|
||||
* statement, granted_roles is a list of AccessPriv; the execution code
|
||||
* should complain if any column lists appear. grantee_roles is a list
|
||||
* should complain if any column lists appear. grantee_roles is a list
|
||||
* of role names, as Value strings.
|
||||
* ----------------------
|
||||
*/
|
||||
@@ -1378,7 +1378,7 @@ typedef struct AlterDefaultPrivilegesStmt
|
||||
* Copy Statement
|
||||
*
|
||||
* We support "COPY relation FROM file", "COPY relation TO file", and
|
||||
* "COPY (query) TO file". In any given CopyStmt, exactly one of "relation"
|
||||
* "COPY (query) TO file". In any given CopyStmt, exactly one of "relation"
|
||||
* and "query" must be non-NULL.
|
||||
* ----------------------
|
||||
*/
|
||||
@@ -1992,7 +1992,7 @@ typedef struct SecLabelStmt
|
||||
* Declare Cursor Statement
|
||||
*
|
||||
* Note: the "query" field of DeclareCursorStmt is only used in the raw grammar
|
||||
* output. After parse analysis it's set to null, and the Query points to the
|
||||
* output. After parse analysis it's set to null, and the Query points to the
|
||||
* DeclareCursorStmt, not vice versa.
|
||||
* ----------------------
|
||||
*/
|
||||
@@ -2052,7 +2052,7 @@ typedef struct FetchStmt
|
||||
*
|
||||
* This represents creation of an index and/or an associated constraint.
|
||||
* If indexOid isn't InvalidOid, we are not creating an index, just a
|
||||
* UNIQUE/PKEY constraint using an existing index. isconstraint must always
|
||||
* UNIQUE/PKEY constraint using an existing index. isconstraint must always
|
||||
* be true in this case, and the fields describing the index properties are
|
||||
* empty.
|
||||
* ----------------------
|
||||
|
@@ -230,7 +230,7 @@ typedef struct RecursiveUnion
|
||||
* BitmapAnd node -
|
||||
* Generate the intersection of the results of sub-plans.
|
||||
*
|
||||
* The subplans must be of types that yield tuple bitmaps. The targetlist
|
||||
* The subplans must be of types that yield tuple bitmaps. The targetlist
|
||||
* and qual fields of the plan are unused and are always NIL.
|
||||
* ----------------
|
||||
*/
|
||||
@@ -244,7 +244,7 @@ typedef struct BitmapAnd
|
||||
* BitmapOr node -
|
||||
* Generate the union of the results of sub-plans.
|
||||
*
|
||||
* The subplans must be of types that yield tuple bitmaps. The targetlist
|
||||
* The subplans must be of types that yield tuple bitmaps. The targetlist
|
||||
* and qual fields of the plan are unused and are always NIL.
|
||||
* ----------------
|
||||
*/
|
||||
@@ -278,7 +278,7 @@ typedef Scan SeqScan;
|
||||
* in the same form it appeared in the query WHERE condition. Each should
|
||||
* be of the form (indexkey OP comparisonval) or (comparisonval OP indexkey).
|
||||
* The indexkey is a Var or expression referencing column(s) of the index's
|
||||
* base table. The comparisonval might be any expression, but it won't use
|
||||
* base table. The comparisonval might be any expression, but it won't use
|
||||
* any columns of the base table. The expressions are ordered by index
|
||||
* column position (but items referencing the same index column can appear
|
||||
* in any order). indexqualorig is used at runtime only if we have to recheck
|
||||
@@ -288,15 +288,15 @@ typedef Scan SeqScan;
|
||||
* necessary to put the indexkeys on the left, and the indexkeys are replaced
|
||||
* by Var nodes identifying the index columns (varattno is the index column
|
||||
* position, not the base table's column, even though varno is for the base
|
||||
* table). This is a bit hokey ... would be cleaner to use a special-purpose
|
||||
* node type that could not be mistaken for a regular Var. But it will do
|
||||
* table). This is a bit hokey ... would be cleaner to use a special-purpose
|
||||
* node type that could not be mistaken for a regular Var. But it will do
|
||||
* for now.
|
||||
*
|
||||
* indexorderbyorig is similarly the original form of any ORDER BY expressions
|
||||
* that are being implemented by the index, while indexorderby is modified to
|
||||
* have index column Vars on the left-hand side. Here, multiple expressions
|
||||
* must appear in exactly the ORDER BY order, and this is not necessarily the
|
||||
* index column order. Only the expressions are provided, not the auxiliary
|
||||
* index column order. Only the expressions are provided, not the auxiliary
|
||||
* sort-order information from the ORDER BY SortGroupClauses; it's assumed
|
||||
* that the sort ordering is fully determinable from the top-level operators.
|
||||
* indexorderbyorig is unused at run time, but is needed for EXPLAIN.
|
||||
@@ -318,7 +318,7 @@ typedef struct IndexScan
|
||||
* bitmap index scan node
|
||||
*
|
||||
* BitmapIndexScan delivers a bitmap of potential tuple locations;
|
||||
* it does not access the heap itself. The bitmap is used by an
|
||||
* it does not access the heap itself. The bitmap is used by an
|
||||
* ancestor BitmapHeapScan node, possibly after passing through
|
||||
* intermediate BitmapAnd and/or BitmapOr nodes to combine it with
|
||||
* the results of other BitmapIndexScans.
|
||||
@@ -378,13 +378,13 @@ typedef struct TidScan
|
||||
* purposes.
|
||||
*
|
||||
* Note: we store the sub-plan in the type-specific subplan field, not in
|
||||
* the generic lefttree field as you might expect. This is because we do
|
||||
* the generic lefttree field as you might expect. This is because we do
|
||||
* not want plan-tree-traversal routines to recurse into the subplan without
|
||||
* knowing that they are changing Query contexts.
|
||||
*
|
||||
* Note: subrtable is used just to carry the subquery rangetable from
|
||||
* createplan.c to setrefs.c; it should always be NIL by the time the
|
||||
* executor sees the plan. Similarly for subrowmark.
|
||||
* executor sees the plan. Similarly for subrowmark.
|
||||
* ----------------
|
||||
*/
|
||||
typedef struct SubqueryScan
|
||||
@@ -747,7 +747,7 @@ typedef enum RowMarkType
|
||||
* plan-time representation of FOR UPDATE/SHARE clauses
|
||||
*
|
||||
* When doing UPDATE, DELETE, or SELECT FOR UPDATE/SHARE, we create a separate
|
||||
* PlanRowMark node for each non-target relation in the query. Relations that
|
||||
* PlanRowMark node for each non-target relation in the query. Relations that
|
||||
* are not specified as FOR UPDATE/SHARE are marked ROW_MARK_REFERENCE (if
|
||||
* real tables) or ROW_MARK_COPY (if not).
|
||||
*
|
||||
@@ -793,7 +793,7 @@ typedef struct PlanRowMark
|
||||
*
|
||||
* We track the objects on which a PlannedStmt depends in two ways:
|
||||
* relations are recorded as a simple list of OIDs, and everything else
|
||||
* is represented as a list of PlanInvalItems. A PlanInvalItem is designed
|
||||
* is represented as a list of PlanInvalItems. A PlanInvalItem is designed
|
||||
* to be used with the syscache invalidation mechanism, so it identifies a
|
||||
* system catalog entry by cache ID and tuple TID.
|
||||
*/
|
||||
|
@@ -33,7 +33,7 @@
|
||||
*
|
||||
* Note: colnames is a list of Value nodes (always strings). In Alias structs
|
||||
* associated with RTEs, there may be entries corresponding to dropped
|
||||
* columns; these are normally empty strings (""). See parsenodes.h for info.
|
||||
* columns; these are normally empty strings (""). See parsenodes.h for info.
|
||||
*/
|
||||
typedef struct Alias
|
||||
{
|
||||
@@ -215,14 +215,14 @@ typedef struct Param
|
||||
* Aggref
|
||||
*
|
||||
* The aggregate's args list is a targetlist, ie, a list of TargetEntry nodes
|
||||
* (before Postgres 9.0 it was just bare expressions). The non-resjunk TLEs
|
||||
* (before Postgres 9.0 it was just bare expressions). The non-resjunk TLEs
|
||||
* represent the aggregate's regular arguments (if any) and resjunk TLEs can
|
||||
* be added at the end to represent ORDER BY expressions that are not also
|
||||
* arguments. As in a top-level Query, the TLEs can be marked with
|
||||
* ressortgroupref indexes to let them be referenced by SortGroupClause
|
||||
* entries in the aggorder and/or aggdistinct lists. This represents ORDER BY
|
||||
* and DISTINCT operations to be applied to the aggregate input rows before
|
||||
* they are passed to the transition function. The grammar only allows a
|
||||
* they are passed to the transition function. The grammar only allows a
|
||||
* simple "DISTINCT" specifier for the arguments, but we use the full
|
||||
* query-level representation to allow more code sharing.
|
||||
*/
|
||||
@@ -269,7 +269,7 @@ typedef struct WindowFunc
|
||||
* entire new modified array value.
|
||||
*
|
||||
* If reflowerindexpr = NIL, then we are fetching or storing a single array
|
||||
* element at the subscripts given by refupperindexpr. Otherwise we are
|
||||
* element at the subscripts given by refupperindexpr. Otherwise we are
|
||||
* fetching or storing an array slice, that is a rectangular subarray
|
||||
* with lower and upper bounds given by the index expressions.
|
||||
* reflowerindexpr must be the same length as refupperindexpr when it
|
||||
@@ -428,7 +428,7 @@ typedef struct ScalarArrayOpExpr
|
||||
*
|
||||
* Notice the arguments are given as a List. For NOT, of course the list
|
||||
* must always have exactly one element. For AND and OR, the executor can
|
||||
* handle any number of arguments. The parser generally treats AND and OR
|
||||
* handle any number of arguments. The parser generally treats AND and OR
|
||||
* as binary and so it typically only produces two-element lists, but the
|
||||
* optimizer will flatten trees of AND and OR nodes to produce longer lists
|
||||
* when possible. There are also a few special cases where more arguments
|
||||
@@ -451,7 +451,7 @@ typedef struct BoolExpr
|
||||
* SubLink
|
||||
*
|
||||
* A SubLink represents a subselect appearing in an expression, and in some
|
||||
* cases also the combining operator(s) just above it. The subLinkType
|
||||
* cases also the combining operator(s) just above it. The subLinkType
|
||||
* indicates the form of the expression represented:
|
||||
* EXISTS_SUBLINK EXISTS(SELECT ...)
|
||||
* ALL_SUBLINK (lefthand) op ALL (SELECT ...)
|
||||
@@ -478,7 +478,7 @@ typedef struct BoolExpr
|
||||
*
|
||||
* NOTE: in the raw output of gram.y, testexpr contains just the raw form
|
||||
* of the lefthand expression (if any), and operName is the String name of
|
||||
* the combining operator. Also, subselect is a raw parsetree. During parse
|
||||
* the combining operator. Also, subselect is a raw parsetree. During parse
|
||||
* analysis, the parser transforms testexpr into a complete boolean expression
|
||||
* that compares the lefthand value(s) to PARAM_SUBLINK nodes representing the
|
||||
* output columns of the subselect. And subselect is transformed to a Query.
|
||||
@@ -536,7 +536,7 @@ typedef struct SubLink
|
||||
* list). In this case testexpr is NULL to avoid duplication.
|
||||
*
|
||||
* The planner also derives lists of the values that need to be passed into
|
||||
* and out of the subplan. Input values are represented as a list "args" of
|
||||
* and out of the subplan. Input values are represented as a list "args" of
|
||||
* expressions to be evaluated in the outer-query context (currently these
|
||||
* args are always just Vars, but in principle they could be any expression).
|
||||
* The values are assigned to the global PARAM_EXEC params indexed by parParam
|
||||
@@ -627,7 +627,7 @@ typedef struct FieldSelect
|
||||
* portion of a column.
|
||||
*
|
||||
* A single FieldStore can actually represent updates of several different
|
||||
* fields. The parser only generates FieldStores with single-element lists,
|
||||
* fields. The parser only generates FieldStores with single-element lists,
|
||||
* but the planner will collapse multiple updates of the same base column
|
||||
* into one FieldStore.
|
||||
* ----------------
|
||||
@@ -759,7 +759,7 @@ typedef struct CollateExpr
|
||||
* and the testexpr in the second case.
|
||||
*
|
||||
* In the raw grammar output for the second form, the condition expressions
|
||||
* of the WHEN clauses are just the comparison values. Parse analysis
|
||||
* of the WHEN clauses are just the comparison values. Parse analysis
|
||||
* converts these to valid boolean expressions of the form
|
||||
* CaseTestExpr '=' compexpr
|
||||
* where the CaseTestExpr node is a placeholder that emits the correct
|
||||
@@ -833,10 +833,10 @@ typedef struct ArrayExpr
|
||||
*
|
||||
* Note: the list of fields must have a one-for-one correspondence with
|
||||
* physical fields of the associated rowtype, although it is okay for it
|
||||
* to be shorter than the rowtype. That is, the N'th list element must
|
||||
* to be shorter than the rowtype. That is, the N'th list element must
|
||||
* match up with the N'th physical field. When the N'th physical field
|
||||
* is a dropped column (attisdropped) then the N'th list element can just
|
||||
* be a NULL constant. (This case can only occur for named composite types,
|
||||
* be a NULL constant. (This case can only occur for named composite types,
|
||||
* not RECORD types, since those are built from the RowExpr itself rather
|
||||
* than vice versa.) It is important not to assume that length(args) is
|
||||
* the same as the number of columns logically present in the rowtype.
|
||||
@@ -857,7 +857,7 @@ typedef struct RowExpr
|
||||
* Note: we deliberately do NOT store a typmod. Although a typmod will be
|
||||
* associated with specific RECORD types at runtime, it will differ for
|
||||
* different backends, and so cannot safely be stored in stored
|
||||
* parsetrees. We must assume typmod -1 for a RowExpr node.
|
||||
* parsetrees. We must assume typmod -1 for a RowExpr node.
|
||||
*
|
||||
* We don't need to store a collation either. The result type is
|
||||
* necessarily composite, and composite types never have a collation.
|
||||
@@ -943,7 +943,7 @@ typedef struct MinMaxExpr
|
||||
* 'args' carries all other arguments.
|
||||
*
|
||||
* Note: result type/typmod/collation are not stored, but can be deduced
|
||||
* from the XmlExprOp. The type/typmod fields are just used for display
|
||||
* from the XmlExprOp. The type/typmod fields are just used for display
|
||||
* purposes, and are NOT necessarily the true result type of the node.
|
||||
* (We also use type == InvalidOid to mark a not-yet-parse-analyzed XmlExpr.)
|
||||
*/
|
||||
@@ -1029,8 +1029,8 @@ typedef struct BooleanTest
|
||||
*
|
||||
* CoerceToDomain represents the operation of coercing a value to a domain
|
||||
* type. At runtime (and not before) the precise set of constraints to be
|
||||
* checked will be determined. If the value passes, it is returned as the
|
||||
* result; if not, an error is raised. Note that this is equivalent to
|
||||
* checked will be determined. If the value passes, it is returned as the
|
||||
* result; if not, an error is raised. Note that this is equivalent to
|
||||
* RelabelType in the scenario where no constraints are applied.
|
||||
*/
|
||||
typedef struct CoerceToDomain
|
||||
@@ -1046,7 +1046,7 @@ typedef struct CoerceToDomain
|
||||
|
||||
/*
|
||||
* Placeholder node for the value to be processed by a domain's check
|
||||
* constraint. This is effectively like a Param, but can be implemented more
|
||||
* constraint. This is effectively like a Param, but can be implemented more
|
||||
* simply since we need only one replacement value at a time.
|
||||
*
|
||||
* Note: the typeId/typeMod/collation will be set from the domain's base type,
|
||||
@@ -1066,7 +1066,7 @@ typedef struct CoerceToDomainValue
|
||||
* Placeholder node for a DEFAULT marker in an INSERT or UPDATE command.
|
||||
*
|
||||
* This is not an executable expression: it must be replaced by the actual
|
||||
* column default expression during rewriting. But it is convenient to
|
||||
* column default expression during rewriting. But it is convenient to
|
||||
* treat it as an expression node during parsing and rewriting.
|
||||
*/
|
||||
typedef struct SetToDefault
|
||||
@@ -1108,14 +1108,14 @@ typedef struct CurrentOfExpr
|
||||
* single expression tree.
|
||||
*
|
||||
* In a SELECT's targetlist, resno should always be equal to the item's
|
||||
* ordinal position (counting from 1). However, in an INSERT or UPDATE
|
||||
* ordinal position (counting from 1). However, in an INSERT or UPDATE
|
||||
* targetlist, resno represents the attribute number of the destination
|
||||
* column for the item; so there may be missing or out-of-order resnos.
|
||||
* It is even legal to have duplicated resnos; consider
|
||||
* UPDATE table SET arraycol[1] = ..., arraycol[2] = ..., ...
|
||||
* The two meanings come together in the executor, because the planner
|
||||
* transforms INSERT/UPDATE tlists into a normalized form with exactly
|
||||
* one entry for each column of the destination table. Before that's
|
||||
* one entry for each column of the destination table. Before that's
|
||||
* happened, however, it is risky to assume that resno == position.
|
||||
* Generally get_tle_by_resno() should be used rather than list_nth()
|
||||
* to fetch tlist entries by resno, and only in SELECT should you assume
|
||||
@@ -1124,25 +1124,25 @@ typedef struct CurrentOfExpr
|
||||
* resname is required to represent the correct column name in non-resjunk
|
||||
* entries of top-level SELECT targetlists, since it will be used as the
|
||||
* column title sent to the frontend. In most other contexts it is only
|
||||
* a debugging aid, and may be wrong or even NULL. (In particular, it may
|
||||
* a debugging aid, and may be wrong or even NULL. (In particular, it may
|
||||
* be wrong in a tlist from a stored rule, if the referenced column has been
|
||||
* renamed by ALTER TABLE since the rule was made. Also, the planner tends
|
||||
* renamed by ALTER TABLE since the rule was made. Also, the planner tends
|
||||
* to store NULL rather than look up a valid name for tlist entries in
|
||||
* non-toplevel plan nodes.) In resjunk entries, resname should be either
|
||||
* a specific system-generated name (such as "ctid") or NULL; anything else
|
||||
* risks confusing ExecGetJunkAttribute!
|
||||
*
|
||||
* ressortgroupref is used in the representation of ORDER BY, GROUP BY, and
|
||||
* DISTINCT items. Targetlist entries with ressortgroupref=0 are not
|
||||
* DISTINCT items. Targetlist entries with ressortgroupref=0 are not
|
||||
* sort/group items. If ressortgroupref>0, then this item is an ORDER BY,
|
||||
* GROUP BY, and/or DISTINCT target value. No two entries in a targetlist
|
||||
* GROUP BY, and/or DISTINCT target value. No two entries in a targetlist
|
||||
* may have the same nonzero ressortgroupref --- but there is no particular
|
||||
* meaning to the nonzero values, except as tags. (For example, one must
|
||||
* not assume that lower ressortgroupref means a more significant sort key.)
|
||||
* The order of the associated SortGroupClause lists determine the semantics.
|
||||
*
|
||||
* resorigtbl/resorigcol identify the source of the column, if it is a
|
||||
* simple reference to a column of a base table (or view). If it is not
|
||||
* simple reference to a column of a base table (or view). If it is not
|
||||
* a simple reference, these fields are zeroes.
|
||||
*
|
||||
* If resjunk is true then the column is a working column (such as a sort key)
|
||||
@@ -1182,7 +1182,7 @@ typedef struct TargetEntry
|
||||
*
|
||||
* NOTE: the qualification expressions present in JoinExpr nodes are
|
||||
* *in addition to* the query's main WHERE clause, which appears as the
|
||||
* qual of the top-level FromExpr. The reason for associating quals with
|
||||
* qual of the top-level FromExpr. The reason for associating quals with
|
||||
* specific nodes in the jointree is that the position of a qual is critical
|
||||
* when outer joins are present. (If we enforce a qual too soon or too late,
|
||||
* that may cause the outer join to produce the wrong set of NULL-extended
|
||||
@@ -1218,7 +1218,7 @@ typedef struct RangeTblRef
|
||||
* If he writes NATURAL then parse analysis generates the equivalent USING()
|
||||
* list, and from that fills in "quals" with the right equality comparisons.
|
||||
* If he writes USING() then "quals" is filled with equality comparisons.
|
||||
* If he writes ON() then only "quals" is set. Note that NATURAL/USING
|
||||
* If he writes ON() then only "quals" is set. Note that NATURAL/USING
|
||||
* are not equivalent to ON() since they also affect the output column list.
|
||||
*
|
||||
* alias is an Alias node representing the AS alias-clause attached to the
|
||||
@@ -1227,7 +1227,7 @@ typedef struct RangeTblRef
|
||||
* restricts visibility of the tables/columns inside it.
|
||||
*
|
||||
* During parse analysis, an RTE is created for the Join, and its index
|
||||
* is filled into rtindex. This RTE is present mainly so that Vars can
|
||||
* is filled into rtindex. This RTE is present mainly so that Vars can
|
||||
* be created that refer to the outputs of the join. The planner sometimes
|
||||
* generates JoinExprs internally; these can have rtindex = 0 if there are
|
||||
* no join alias variables referencing such joins.
|
||||
|
@@ -117,7 +117,7 @@ typedef struct PlannerGlobal
|
||||
*
|
||||
* This struct is conventionally called "root" in all the planner routines.
|
||||
* It holds links to all of the planner's working state, in addition to the
|
||||
* original Query. Note that at present the planner extensively modifies
|
||||
* original Query. Note that at present the planner extensively modifies
|
||||
* the passed-in Query data structure; someday that should stop.
|
||||
*----------
|
||||
*/
|
||||
@@ -135,7 +135,7 @@ typedef struct PlannerInfo
|
||||
|
||||
/*
|
||||
* simple_rel_array holds pointers to "base rels" and "other rels" (see
|
||||
* comments for RelOptInfo for more info). It is indexed by rangetable
|
||||
* comments for RelOptInfo for more info). It is indexed by rangetable
|
||||
* index (so entry 0 is always wasted). Entries can be NULL when an RTE
|
||||
* does not correspond to a base relation, such as a join RTE or an
|
||||
* unreferenced view RTE; or if the RelOptInfo hasn't been made yet.
|
||||
@@ -156,7 +156,7 @@ typedef struct PlannerInfo
|
||||
* considered in this planning run. For small problems we just scan the
|
||||
* list to do lookups, but when there are many join relations we build a
|
||||
* hash table for faster lookups. The hash table is present and valid
|
||||
* when join_rel_hash is not NULL. Note that we still maintain the list
|
||||
* when join_rel_hash is not NULL. Note that we still maintain the list
|
||||
* even when using the hash table for lookups; this simplifies life for
|
||||
* GEQO.
|
||||
*/
|
||||
@@ -278,7 +278,7 @@ typedef struct PlannerInfo
|
||||
* Currently the only kind of otherrels are those made for member relations
|
||||
* of an "append relation", that is an inheritance set or UNION ALL subquery.
|
||||
* An append relation has a parent RTE that is a base rel, which represents
|
||||
* the entire append relation. The member RTEs are otherrels. The parent
|
||||
* the entire append relation. The member RTEs are otherrels. The parent
|
||||
* is present in the query join tree but the members are not. The member
|
||||
* RTEs and otherrels are used to plan the scans of the individual tables or
|
||||
* subqueries of the append set; then the parent baserel is given Append
|
||||
@@ -290,7 +290,7 @@ typedef struct PlannerInfo
|
||||
* alias Vars are expanded to non-aliased form during preprocess_expression.
|
||||
*
|
||||
* Parts of this data structure are specific to various scan and join
|
||||
* mechanisms. It didn't seem worth creating new node types for them.
|
||||
* mechanisms. It didn't seem worth creating new node types for them.
|
||||
*
|
||||
* relids - Set of base-relation identifiers; it is a base relation
|
||||
* if there is just one, a join relation if more than one
|
||||
@@ -515,7 +515,7 @@ typedef struct IndexOptInfo
|
||||
* equal to each other, where "equal" is according to the rules of the btree
|
||||
* operator family(s) shown in ec_opfamilies, as well as the collation shown
|
||||
* by ec_collation. (We restrict an EC to contain only equalities whose
|
||||
* operators belong to the same set of opfamilies. This could probably be
|
||||
* operators belong to the same set of opfamilies. This could probably be
|
||||
* relaxed, but for now it's not worth the trouble, since nearly all equality
|
||||
* operators belong to only one btree opclass anyway. Similarly, we suppose
|
||||
* that all or none of the input datatypes are collatable, so that a single
|
||||
@@ -525,7 +525,7 @@ typedef struct IndexOptInfo
|
||||
* us represent knowledge about different sort orderings being equivalent.
|
||||
* Since every PathKey must reference an EquivalenceClass, we will end up
|
||||
* with single-member EquivalenceClasses whenever a sort key expression has
|
||||
* not been equivalenced to anything else. It is also possible that such an
|
||||
* not been equivalenced to anything else. It is also possible that such an
|
||||
* EquivalenceClass will contain a volatile expression ("ORDER BY random()"),
|
||||
* which is a case that can't arise otherwise since clauses containing
|
||||
* volatile functions are never considered mergejoinable. We mark such
|
||||
@@ -538,7 +538,7 @@ typedef struct IndexOptInfo
|
||||
* We allow equality clauses appearing below the nullable side of an outer join
|
||||
* to form EquivalenceClasses, but these have a slightly different meaning:
|
||||
* the included values might be all NULL rather than all the same non-null
|
||||
* values. See src/backend/optimizer/README for more on that point.
|
||||
* values. See src/backend/optimizer/README for more on that point.
|
||||
*
|
||||
* NB: if ec_merged isn't NULL, this class has been merged into another, and
|
||||
* should be ignored in favor of using the pointed-to class.
|
||||
@@ -587,7 +587,7 @@ typedef struct EquivalenceClass
|
||||
*
|
||||
* em_datatype is usually the same as exprType(em_expr), but can be
|
||||
* different when dealing with a binary-compatible opfamily; in particular
|
||||
* anyarray_ops would never work without this. Use em_datatype when
|
||||
* anyarray_ops would never work without this. Use em_datatype when
|
||||
* looking up a specific btree operator to work with this expression.
|
||||
*/
|
||||
typedef struct EquivalenceMember
|
||||
@@ -616,7 +616,7 @@ typedef struct EquivalenceMember
|
||||
* information.)
|
||||
*
|
||||
* Note: pk_strategy is either BTLessStrategyNumber (for ASC) or
|
||||
* BTGreaterStrategyNumber (for DESC). We assume that all ordering-capable
|
||||
* BTGreaterStrategyNumber (for DESC). We assume that all ordering-capable
|
||||
* index types will use btree-compatible strategy numbers.
|
||||
*/
|
||||
|
||||
@@ -728,11 +728,11 @@ typedef struct IndexPath
|
||||
*
|
||||
* The individual indexscans are represented by IndexPath nodes, and any
|
||||
* logic on top of them is represented by a tree of BitmapAndPath and
|
||||
* BitmapOrPath nodes. Notice that we can use the same IndexPath node both
|
||||
* BitmapOrPath nodes. Notice that we can use the same IndexPath node both
|
||||
* to represent a regular IndexScan plan, and as the child of a BitmapHeapPath
|
||||
* that represents scanning the same index using a BitmapIndexScan. The
|
||||
* startup_cost and total_cost figures of an IndexPath always represent the
|
||||
* costs to use it as a regular IndexScan. The costs of a BitmapIndexScan
|
||||
* costs to use it as a regular IndexScan. The costs of a BitmapIndexScan
|
||||
* can be computed using the IndexPath's indextotalcost and indexselectivity.
|
||||
*
|
||||
* BitmapHeapPaths can be nestloop inner indexscans. The isjoininner and
|
||||
@@ -855,7 +855,7 @@ typedef struct MaterialPath
|
||||
*
|
||||
* This is unlike the other Path nodes in that it can actually generate
|
||||
* different plans: either hash-based or sort-based implementation, or a
|
||||
* no-op if the input path can be proven distinct already. The decision
|
||||
* no-op if the input path can be proven distinct already. The decision
|
||||
* is sufficiently localized that it's not worth having separate Path node
|
||||
* types. (Note: in the no-op case, we could eliminate the UniquePath node
|
||||
* entirely and just return the subpath; but it's convenient to have a
|
||||
@@ -981,7 +981,7 @@ typedef struct HashPath
|
||||
* When we construct a join rel that includes all the base rels referenced
|
||||
* in a multi-relation restriction clause, we place that clause into the
|
||||
* joinrestrictinfo lists of paths for the join rel, if neither left nor
|
||||
* right sub-path includes all base rels referenced in the clause. The clause
|
||||
* right sub-path includes all base rels referenced in the clause. The clause
|
||||
* will be applied at that join level, and will not propagate any further up
|
||||
* the join tree. (Note: the "predicate migration" code was once intended to
|
||||
* push restriction clauses up and down the plan tree based on evaluation
|
||||
@@ -1021,13 +1021,13 @@ typedef struct HashPath
|
||||
* that appeared elsewhere in the tree and were pushed down to the join rel
|
||||
* because they used no other rels. That's what the is_pushed_down flag is
|
||||
* for; it tells us that a qual is not an OUTER JOIN qual for the set of base
|
||||
* rels listed in required_relids. A clause that originally came from WHERE
|
||||
* rels listed in required_relids. A clause that originally came from WHERE
|
||||
* or an INNER JOIN condition will *always* have its is_pushed_down flag set.
|
||||
* It's possible for an OUTER JOIN clause to be marked is_pushed_down too,
|
||||
* if we decide that it can be pushed down into the nullable side of the join.
|
||||
* In that case it acts as a plain filter qual for wherever it gets evaluated.
|
||||
* (In short, is_pushed_down is only false for non-degenerate outer join
|
||||
* conditions. Possibly we should rename it to reflect that meaning?)
|
||||
* conditions. Possibly we should rename it to reflect that meaning?)
|
||||
*
|
||||
* RestrictInfo nodes also contain an outerjoin_delayed flag, which is true
|
||||
* if the clause's applicability must be delayed due to any outer joins
|
||||
@@ -1037,10 +1037,10 @@ typedef struct HashPath
|
||||
* forced null by some outer join below the clause. outerjoin_delayed = true
|
||||
* is subtly different from nullable_relids != NULL: a clause might reference
|
||||
* some nullable rels and yet not be outerjoin_delayed because it also
|
||||
* references all the other rels of the outer join(s). A clause that is not
|
||||
* references all the other rels of the outer join(s). A clause that is not
|
||||
* outerjoin_delayed can be enforced anywhere it is computable.
|
||||
*
|
||||
* In general, the referenced clause might be arbitrarily complex. The
|
||||
* In general, the referenced clause might be arbitrarily complex. The
|
||||
* kinds of clauses we can handle as indexscan quals, mergejoin clauses,
|
||||
* or hashjoin clauses are limited (e.g., no volatile functions). The code
|
||||
* for each kind of path is responsible for identifying the restrict clauses
|
||||
@@ -1065,7 +1065,7 @@ typedef struct HashPath
|
||||
*
|
||||
* The pseudoconstant flag is set true if the clause contains no Vars of
|
||||
* the current query level and no volatile functions. Such a clause can be
|
||||
* pulled out and used as a one-time qual in a gating Result node. We keep
|
||||
* pulled out and used as a one-time qual in a gating Result node. We keep
|
||||
* pseudoconstant clauses in the same lists as other RestrictInfos so that
|
||||
* the regular clause-pushing machinery can assign them to the correct join
|
||||
* level, but they need to be treated specially for cost and selectivity
|
||||
@@ -1075,7 +1075,7 @@ typedef struct HashPath
|
||||
*
|
||||
* When join clauses are generated from EquivalenceClasses, there may be
|
||||
* several equally valid ways to enforce join equivalence, of which we need
|
||||
* apply only one. We mark clauses of this kind by setting parent_ec to
|
||||
* apply only one. We mark clauses of this kind by setting parent_ec to
|
||||
* point to the generating EquivalenceClass. Multiple clauses with the same
|
||||
* parent_ec in the same join are redundant.
|
||||
*/
|
||||
@@ -1201,8 +1201,8 @@ typedef struct InnerIndexscanInfo
|
||||
|
||||
/*
|
||||
* Placeholder node for an expression to be evaluated below the top level
|
||||
* of a plan tree. This is used during planning to represent the contained
|
||||
* expression. At the end of the planning process it is replaced by either
|
||||
* of a plan tree. This is used during planning to represent the contained
|
||||
* expression. At the end of the planning process it is replaced by either
|
||||
* the contained expression or a Var referring to a lower-level evaluation of
|
||||
* the contained expression. Typically the evaluation occurs below an outer
|
||||
* join, and Var references above the outer join might thereby yield NULL
|
||||
@@ -1226,9 +1226,9 @@ typedef struct PlaceHolderVar
|
||||
* "Special join" info.
|
||||
*
|
||||
* One-sided outer joins constrain the order of joining partially but not
|
||||
* completely. We flatten such joins into the planner's top-level list of
|
||||
* completely. We flatten such joins into the planner's top-level list of
|
||||
* relations to join, but record information about each outer join in a
|
||||
* SpecialJoinInfo struct. These structs are kept in the PlannerInfo node's
|
||||
* SpecialJoinInfo struct. These structs are kept in the PlannerInfo node's
|
||||
* join_info_list.
|
||||
*
|
||||
* Similarly, semijoins and antijoins created by flattening IN (subselect)
|
||||
@@ -1256,7 +1256,7 @@ typedef struct PlaceHolderVar
|
||||
* to be evaluated after this join is formed (because it references the RHS).
|
||||
* Any outer joins that have such a clause and this join in their RHS cannot
|
||||
* commute with this join, because that would leave noplace to check the
|
||||
* pushed-down clause. (We don't track this for FULL JOINs, either.)
|
||||
* pushed-down clause. (We don't track this for FULL JOINs, either.)
|
||||
*
|
||||
* join_quals is an implicit-AND list of the quals syntactically associated
|
||||
* with the join (they may or may not end up being applied at the join level).
|
||||
@@ -1341,7 +1341,7 @@ typedef struct AppendRelInfo
|
||||
/*
|
||||
* For an inheritance appendrel, the parent and child are both regular
|
||||
* relations, and we store their rowtype OIDs here for use in translating
|
||||
* whole-row Vars. For a UNION-ALL appendrel, the parent and child are
|
||||
* whole-row Vars. For a UNION-ALL appendrel, the parent and child are
|
||||
* both subqueries with no named rowtype, and we store InvalidOid here.
|
||||
*/
|
||||
Oid parent_reltype; /* OID of parent's composite type */
|
||||
@@ -1353,14 +1353,14 @@ typedef struct AppendRelInfo
|
||||
* used to translate Vars referencing the parent rel into references to
|
||||
* the child. A list element is NULL if it corresponds to a dropped
|
||||
* column of the parent (this is only possible for inheritance cases, not
|
||||
* UNION ALL). The list elements are always simple Vars for inheritance
|
||||
* UNION ALL). The list elements are always simple Vars for inheritance
|
||||
* cases, but can be arbitrary expressions in UNION ALL cases.
|
||||
*
|
||||
* Notice we only store entries for user columns (attno > 0). Whole-row
|
||||
* Vars are special-cased, and system columns (attno < 0) need no special
|
||||
* translation since their attnos are the same for all tables.
|
||||
*
|
||||
* Caution: the Vars have varlevelsup = 0. Be careful to adjust as needed
|
||||
* Caution: the Vars have varlevelsup = 0. Be careful to adjust as needed
|
||||
* when copying into a subquery.
|
||||
*/
|
||||
List *translated_vars; /* Expressions in the child's Vars */
|
||||
@@ -1377,7 +1377,7 @@ typedef struct AppendRelInfo
|
||||
* For each distinct placeholder expression generated during planning, we
|
||||
* store a PlaceHolderInfo node in the PlannerInfo node's placeholder_list.
|
||||
* This stores info that is needed centrally rather than in each copy of the
|
||||
* PlaceHolderVar. The phid fields identify which PlaceHolderInfo goes with
|
||||
* PlaceHolderVar. The phid fields identify which PlaceHolderInfo goes with
|
||||
* each PlaceHolderVar. Note that phid is unique throughout a planner run,
|
||||
* not just within a query level --- this is so that we need not reassign ID's
|
||||
* when pulling a subquery into its parent.
|
||||
|
@@ -26,7 +26,7 @@
|
||||
|
||||
|
||||
/*
|
||||
* Actual bitmap representation is private to tidbitmap.c. Callers can
|
||||
* Actual bitmap representation is private to tidbitmap.c. Callers can
|
||||
* do IsA(x, TIDBitmap) on it, but nothing else.
|
||||
*/
|
||||
typedef struct TIDBitmap TIDBitmap;
|
||||
|
@@ -29,7 +29,7 @@
|
||||
*
|
||||
* (Before Postgres 7.0, we used a double to represent T_Float,
|
||||
* but that creates loss-of-precision problems when the value is
|
||||
* ultimately destined to be converted to NUMERIC. Since Value nodes
|
||||
* ultimately destined to be converted to NUMERIC. Since Value nodes
|
||||
* are only used in the parsing process, not for runtime data, it's
|
||||
* better to use the more general representation.)
|
||||
*
|
||||
|
@@ -29,7 +29,7 @@
|
||||
#include "parser/gram.h"
|
||||
|
||||
/*
|
||||
* The YY_EXTRA data that a flex scanner allows us to pass around. Private
|
||||
* The YY_EXTRA data that a flex scanner allows us to pass around. Private
|
||||
* state needed for raw parsing/lexing goes here.
|
||||
*/
|
||||
typedef struct base_yy_extra_type
|
||||
|
@@ -38,7 +38,7 @@ typedef Node *(*CoerceParamHook) (ParseState *pstate, Param *param,
|
||||
* links to current parse state of outer query.
|
||||
*
|
||||
* p_sourcetext: source string that generated the raw parsetree being
|
||||
* analyzed, or NULL if not available. (The string is used only to
|
||||
* analyzed, or NULL if not available. (The string is used only to
|
||||
* generate cursor positions in error messages: we need it to convert
|
||||
* byte-wise locations in parse structures to character-wise cursor
|
||||
* positions.)
|
||||
@@ -72,7 +72,7 @@ typedef Node *(*CoerceParamHook) (ParseState *pstate, Param *param,
|
||||
* to make an RTE before you can access a CTE.
|
||||
*
|
||||
* p_future_ctes: list of CommonTableExprs (WITH items) that are not yet
|
||||
* visible due to scope rules. This is used to help improve error messages.
|
||||
* visible due to scope rules. This is used to help improve error messages.
|
||||
*
|
||||
* p_parent_cte: CommonTableExpr that immediately contains the current query,
|
||||
* if any.
|
||||
|
@@ -4,7 +4,7 @@
|
||||
* API for the core scanner (flex machine)
|
||||
*
|
||||
* The core scanner is also used by PL/pgsql, so we provide a public API
|
||||
* for it. However, the rest of the backend is only expected to use the
|
||||
* for it. However, the rest of the backend is only expected to use the
|
||||
* higher-level API provided by parser.h.
|
||||
*
|
||||
*
|
||||
@@ -58,7 +58,7 @@ typedef union core_YYSTYPE
|
||||
|
||||
/*
|
||||
* The YY_EXTRA data that a flex scanner allows us to pass around.
|
||||
* Private state needed by the core scanner goes here. Note that the actual
|
||||
* Private state needed by the core scanner goes here. Note that the actual
|
||||
* yy_extra struct may be larger and have this as its first component, thus
|
||||
* allowing the calling parser to keep some fields of its own in YY_EXTRA.
|
||||
*/
|
||||
|
@@ -3,7 +3,7 @@
|
||||
*
|
||||
* This file contains various configuration symbols and limits. In
|
||||
* all cases, changing them is only useful in very rare situations or
|
||||
* for developers. If you edit any of these, be sure to do a *full*
|
||||
* for developers. If you edit any of these, be sure to do a *full*
|
||||
* rebuild (and an initdb if noted).
|
||||
*
|
||||
* src/include/pg_config_manual.h
|
||||
@@ -55,8 +55,8 @@
|
||||
|
||||
/*
|
||||
* Define this if you want to allow the lo_import and lo_export SQL
|
||||
* functions to be executed by ordinary users. By default these
|
||||
* functions are only available to the Postgres superuser. CAUTION:
|
||||
* functions to be executed by ordinary users. By default these
|
||||
* functions are only available to the Postgres superuser. CAUTION:
|
||||
* These functions are SECURITY HOLES since they can read and write
|
||||
* any file that the PostgreSQL server has permission to access. If
|
||||
* you turn this on, don't say we didn't warn you.
|
||||
@@ -135,7 +135,7 @@
|
||||
|
||||
/*
|
||||
* This is the default directory in which AF_UNIX socket files are
|
||||
* placed. Caution: changing this risks breaking your existing client
|
||||
* placed. Caution: changing this risks breaking your existing client
|
||||
* applications, which are likely to continue to look in the old
|
||||
* directory. But if you just hate the idea of sockets in /tmp,
|
||||
* here's where to twiddle it. You can also override this at runtime
|
||||
@@ -148,7 +148,7 @@
|
||||
* MAX_RANDOM_VALUE. Currently, all known implementations yield
|
||||
* 0..2^31-1, so we just hardwire this constant. We could do a
|
||||
* configure test if it proves to be necessary. CAUTION: Think not to
|
||||
* replace this with RAND_MAX. RAND_MAX defines the maximum value of
|
||||
* replace this with RAND_MAX. RAND_MAX defines the maximum value of
|
||||
* the older rand() function, which is often different from --- and
|
||||
* considerably inferior to --- random().
|
||||
*/
|
||||
@@ -188,7 +188,7 @@
|
||||
|
||||
/*
|
||||
* Define this to check memory allocation errors (scribbling on more
|
||||
* bytes than were allocated). Right now, this gets defined
|
||||
* bytes than were allocated). Right now, this gets defined
|
||||
* automatically if --enable-cassert.
|
||||
*/
|
||||
#ifdef USE_ASSERT_CHECKING
|
||||
@@ -198,7 +198,7 @@
|
||||
/*
|
||||
* Define this to cause palloc()'d memory to be filled with random data, to
|
||||
* facilitate catching code that depends on the contents of uninitialized
|
||||
* memory. Caution: this is horrendously expensive.
|
||||
* memory. Caution: this is horrendously expensive.
|
||||
*/
|
||||
/* #define RANDOMIZE_ALLOCATED_MEMORY */
|
||||
|
||||
|
@@ -120,7 +120,7 @@ typedef enum PgStat_Single_Reset_Type
|
||||
*
|
||||
* Many of the event counters are nontransactional, ie, we count events
|
||||
* in committed and aborted transactions alike. For these, we just count
|
||||
* directly in the PgStat_TableStatus. However, delta_live_tuples,
|
||||
* directly in the PgStat_TableStatus. However, delta_live_tuples,
|
||||
* delta_dead_tuples, and changed_tuples must be derived from event counts
|
||||
* with awareness of whether the transaction or subtransaction committed or
|
||||
* aborted. Hence, we also keep a stack of per-(sub)transaction status
|
||||
|
@@ -159,7 +159,7 @@ extern unsigned char pg_ascii_tolower(unsigned char ch);
|
||||
|
||||
/*
|
||||
* Versions of libintl >= 0.13 try to replace printf() and friends with
|
||||
* macros to their own versions that understand the %$ format. We do the
|
||||
* macros to their own versions that understand the %$ format. We do the
|
||||
* same, so disable their macros, if they exist.
|
||||
*/
|
||||
#ifdef vsnprintf
|
||||
|
@@ -4,7 +4,7 @@
|
||||
* As of July 2007, all known versions of the Linux kernel will sometimes
|
||||
* return EIDRM for a shmctl() operation when EINVAL is correct (it happens
|
||||
* when the low-order 15 bits of the supplied shm ID match the slot number
|
||||
* assigned to a newer shmem segment). We deal with this by assuming that
|
||||
* assigned to a newer shmem segment). We deal with this by assuming that
|
||||
* EIDRM means EINVAL in PGSharedMemoryIsInUse(). This is reasonably safe
|
||||
* since in fact Linux has no excuse for ever returning EIDRM; it doesn't
|
||||
* track removed segments in a way that would allow distinguishing them from
|
||||
|
@@ -116,7 +116,7 @@
|
||||
* Signal stuff
|
||||
*
|
||||
* For WIN32, there is no wait() call so there are no wait() macros
|
||||
* to interpret the return value of system(). Instead, system()
|
||||
* to interpret the return value of system(). Instead, system()
|
||||
* return values < 0x100 are used for exit() termination, and higher
|
||||
* values are used to indicated non-exit() termination, which is
|
||||
* similar to a unix-style signal exit (think SIGSEGV ==
|
||||
@@ -154,7 +154,7 @@
|
||||
* NTSTATUS.H from the Windows NT DDK.
|
||||
*
|
||||
* Some day we might want to print descriptions for the most common
|
||||
* exceptions, rather than printing an include file name. We could use
|
||||
* exceptions, rather than printing an include file name. We could use
|
||||
* RtlNtStatusToDosError() and pass to FormatMessage(), which can print
|
||||
* the text of error values, but MinGW does not support
|
||||
* RtlNtStatusToDosError().
|
||||
|
@@ -10,8 +10,8 @@
|
||||
* high-precision-timing APIs on yet other platforms.
|
||||
*
|
||||
* The basic data type is instr_time, which all callers should treat as an
|
||||
* opaque typedef. instr_time can store either an absolute time (of
|
||||
* unspecified reference time) or an interval. The operations provided
|
||||
* opaque typedef. instr_time can store either an absolute time (of
|
||||
* unspecified reference time) or an interval. The operations provided
|
||||
* for it are:
|
||||
*
|
||||
* INSTR_TIME_IS_ZERO(t) is t equal to zero?
|
||||
|
@@ -33,7 +33,7 @@
|
||||
* in the backend environment, but are of no interest outside the backend.
|
||||
*
|
||||
* Simple type definitions live in c.h, where they are shared with
|
||||
* postgres_fe.h. We do that since those type definitions are needed by
|
||||
* postgres_fe.h. We do that since those type definitions are needed by
|
||||
* frontend modules that want to deal with binary data transmission to or
|
||||
* from the backend. Type definitions in this file should be for
|
||||
* representations that never escape the backend, such as Datum or
|
||||
@@ -55,7 +55,7 @@
|
||||
|
||||
/*
|
||||
* struct varatt_external is a "TOAST pointer", that is, the information
|
||||
* needed to fetch a stored-out-of-line Datum. The data is compressed
|
||||
* needed to fetch a stored-out-of-line Datum. The data is compressed
|
||||
* if and only if va_extsize < va_rawsize - VARHDRSZ. This struct must not
|
||||
* contain any padding, because we sometimes compare pointers using memcmp.
|
||||
*
|
||||
@@ -127,7 +127,7 @@ typedef struct
|
||||
* The "xxx" bits are the length field (which includes itself in all cases).
|
||||
* In the big-endian case we mask to extract the length, in the little-endian
|
||||
* case we shift. Note that in both cases the flag bits are in the physically
|
||||
* first byte. Also, it is not possible for a 1-byte length word to be zero;
|
||||
* first byte. Also, it is not possible for a 1-byte length word to be zero;
|
||||
* this lets us disambiguate alignment padding bytes from the start of an
|
||||
* unaligned datum. (We now *require* pad bytes to be filled with zero!)
|
||||
*/
|
||||
|
@@ -7,7 +7,7 @@
|
||||
* For example, the Oid type is part of the API of libpq and other libraries.
|
||||
*
|
||||
* Declarations which are specific to a particular interface should
|
||||
* go in the header file for that interface (such as libpq-fe.h). This
|
||||
* go in the header file for that interface (such as libpq-fe.h). This
|
||||
* file is only for fundamental Postgres declarations.
|
||||
*
|
||||
* User-written C functions don't count as "external to Postgres."
|
||||
|
@@ -20,7 +20,7 @@
|
||||
* here is to divide long messages into chunks that are not more than
|
||||
* PIPE_BUF bytes long, which according to POSIX spec must be written into
|
||||
* the pipe atomically. The pipe reader then uses the protocol headers to
|
||||
* reassemble the parts of a message into a single string. The reader can
|
||||
* reassemble the parts of a message into a single string. The reader can
|
||||
* also cope with non-protocol data coming down the pipe, though we cannot
|
||||
* guarantee long strings won't get split apart.
|
||||
*
|
||||
|
@@ -1,5 +1,5 @@
|
||||
/*
|
||||
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
|
||||
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
|
||||
*
|
||||
* Development of this software was funded, in part, by Cray Research Inc.,
|
||||
* UUNET Communications Services Inc., Sun Microsystems Inc., and Scriptics
|
||||
|
@@ -3,7 +3,7 @@
|
||||
/*
|
||||
* regular expressions
|
||||
*
|
||||
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
|
||||
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
|
||||
*
|
||||
* Development of this software was funded, in part, by Cray Research Inc.,
|
||||
* UUNET Communications Services Inc., Sun Microsystems Inc., and Scriptics
|
||||
|
@@ -1,7 +1,7 @@
|
||||
/*
|
||||
* Internal interface definitions, etc., for the reg package
|
||||
*
|
||||
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
|
||||
* Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
|
||||
*
|
||||
* Development of this software was funded, in part, by Cray Research Inc.,
|
||||
* UUNET Communications Services Inc., Sun Microsystems Inc., and Scriptics
|
||||
@@ -126,8 +126,8 @@
|
||||
|
||||
|
||||
/*
|
||||
* We dissect a chr into byts for colormap table indexing. Here we define
|
||||
* a byt, which will be the same as a byte on most machines... The exact
|
||||
* We dissect a chr into byts for colormap table indexing. Here we define
|
||||
* a byt, which will be the same as a byte on most machines... The exact
|
||||
* size of a byt is not critical, but about 8 bits is good, and extraction
|
||||
* of 8-bit chunks is sometimes especially fast.
|
||||
*/
|
||||
@@ -156,9 +156,9 @@ typedef int pcolor; /* what color promotes to */
|
||||
|
||||
/*
|
||||
* A colormap is a tree -- more precisely, a DAG -- indexed at each level
|
||||
* by a byt of the chr, to map the chr to a color efficiently. Because
|
||||
* by a byt of the chr, to map the chr to a color efficiently. Because
|
||||
* lower sections of the tree can be shared, it can exploit the usual
|
||||
* sparseness of such a mapping table. The tree is always NBYTS levels
|
||||
* sparseness of such a mapping table. The tree is always NBYTS levels
|
||||
* deep (in the past it was shallower during construction but was "filled"
|
||||
* to full depth at the end of that); areas that are unaltered as yet point
|
||||
* to "fill blocks" which are entirely WHITE in color.
|
||||
|
@@ -81,7 +81,7 @@ typedef struct
|
||||
} StandbyHSFeedbackMessage;
|
||||
|
||||
/*
|
||||
* Maximum data payload in a WAL data message. Must be >= XLOG_BLCKSZ.
|
||||
* Maximum data payload in a WAL data message. Must be >= XLOG_BLCKSZ.
|
||||
*
|
||||
* We don't have a good idea of what a good value would be; there's some
|
||||
* overhead per message in both walsender and walreceiver, but on the other
|
||||
|
@@ -69,7 +69,7 @@ typedef struct
|
||||
/*
|
||||
* latestChunkStart is the starting byte position of the current "batch"
|
||||
* of received WAL. It's actually the same as the previous value of
|
||||
* receivedUpto before the last flush to disk. Startup process can use
|
||||
* receivedUpto before the last flush to disk. Startup process can use
|
||||
* this to detect whether it's keeping up or not.
|
||||
*/
|
||||
XLogRecPtr latestChunkStart;
|
||||
|
@@ -4,7 +4,7 @@
|
||||
* Replacement header file for Snowball stemmer modules
|
||||
*
|
||||
* The Snowball stemmer modules do #include "header.h", and think they
|
||||
* are including snowball/libstemmer/header.h. We adjust the CPPFLAGS
|
||||
* are including snowball/libstemmer/header.h. We adjust the CPPFLAGS
|
||||
* so that this file is found instead, and thereby we can modify the
|
||||
* headers they see. The main point here is to ensure that pg_config.h
|
||||
* is included before any system headers such as <stdio.h>; without that,
|
||||
|
@@ -37,7 +37,7 @@ typedef uint32 BlockNumber;
|
||||
/*
|
||||
* BlockId:
|
||||
*
|
||||
* this is a storage type for BlockNumber. in other words, this type
|
||||
* this is a storage type for BlockNumber. in other words, this type
|
||||
* is used for on-disk structures (e.g., in HeapTupleData) whereas
|
||||
* BlockNumber is the type on which calculations are performed (e.g.,
|
||||
* in access method code).
|
||||
|
@@ -110,9 +110,9 @@ typedef struct buftag
|
||||
*
|
||||
* Note: buf_hdr_lock must be held to examine or change the tag, flags,
|
||||
* usage_count, refcount, or wait_backend_pid fields. buf_id field never
|
||||
* changes after initialization, so does not need locking. freeNext is
|
||||
* changes after initialization, so does not need locking. freeNext is
|
||||
* protected by the BufFreelistLock not buf_hdr_lock. The LWLocks can take
|
||||
* care of themselves. The buf_hdr_lock is *not* used to control access to
|
||||
* care of themselves. The buf_hdr_lock is *not* used to control access to
|
||||
* the data in the buffer!
|
||||
*
|
||||
* An exception is that if we have the buffer pinned, its tag can't change
|
||||
@@ -123,7 +123,7 @@ typedef struct buftag
|
||||
*
|
||||
* We can't physically remove items from a disk page if another backend has
|
||||
* the buffer pinned. Hence, a backend may need to wait for all other pins
|
||||
* to go away. This is signaled by storing its own PID into
|
||||
* to go away. This is signaled by storing its own PID into
|
||||
* wait_backend_pid and setting flag bit BM_PIN_COUNT_WAITER. At present,
|
||||
* there can be only one such waiter per buffer.
|
||||
*
|
||||
|
@@ -26,7 +26,7 @@
|
||||
* disk page is always a slotted page of the form:
|
||||
*
|
||||
* +----------------+---------------------------------+
|
||||
* | PageHeaderData | linp1 linp2 linp3 ... |
|
||||
* | PageHeaderData | linp1 linp2 linp3 ... |
|
||||
* +-----------+----+---------------------------------+
|
||||
* | ... linpN | |
|
||||
* +-----------+--------------------------------------+
|
||||
@@ -34,7 +34,7 @@
|
||||
* | |
|
||||
* | v pd_upper |
|
||||
* +-------------+------------------------------------+
|
||||
* | | tupleN ... |
|
||||
* | | tupleN ... |
|
||||
* +-------------+------------------+-----------------+
|
||||
* | ... tuple3 tuple2 tuple1 | "special space" |
|
||||
* +--------------------------------+-----------------+
|
||||
@@ -65,7 +65,7 @@
|
||||
*
|
||||
* AM-specific per-page data (if any) is kept in the area marked "special
|
||||
* space"; each AM has an "opaque" structure defined somewhere that is
|
||||
* stored as the page trailer. an access method should always
|
||||
* stored as the page trailer. an access method should always
|
||||
* initialize its pages with PageInit and then set its own opaque
|
||||
* fields.
|
||||
*/
|
||||
@@ -104,7 +104,7 @@ typedef uint16 LocationIndex;
|
||||
* like a good idea).
|
||||
*
|
||||
* pd_prune_xid is a hint field that helps determine whether pruning will be
|
||||
* useful. It is currently unused in index pages.
|
||||
* useful. It is currently unused in index pages.
|
||||
*
|
||||
* The page version number and page size are packed together into a single
|
||||
* uint16 field. This is for historical reasons: before PostgreSQL 7.3,
|
||||
|
@@ -4,7 +4,7 @@
|
||||
* POSTGRES inter-process communication definitions.
|
||||
*
|
||||
* This file is misnamed, as it no longer has much of anything directly
|
||||
* to do with IPC. The functionality here is concerned with managing
|
||||
* to do with IPC. The functionality here is concerned with managing
|
||||
* exit-time cleanup for either a postmaster or a backend.
|
||||
*
|
||||
*
|
||||
|
@@ -31,7 +31,7 @@ typedef struct ItemIdData
|
||||
typedef ItemIdData *ItemId;
|
||||
|
||||
/*
|
||||
* lp_flags has these possible states. An UNUSED line pointer is available
|
||||
* lp_flags has these possible states. An UNUSED line pointer is available
|
||||
* for immediate re-use, the other states are not.
|
||||
*/
|
||||
#define LP_UNUSED 0 /* unused (should always have lp_len=0) */
|
||||
|
@@ -29,7 +29,7 @@
|
||||
* tuple header on disk, it's very important not to waste space with
|
||||
* structure padding bytes. The struct is designed to be six bytes long
|
||||
* (it contains three int16 fields) but a few compilers will pad it to
|
||||
* eight bytes unless coerced. We apply appropriate persuasion where
|
||||
* eight bytes unless coerced. We apply appropriate persuasion where
|
||||
* possible, and to cope with unpersuadable compilers, we try to use
|
||||
* "SizeOfIptrData" rather than "sizeof(ItemPointerData)" when computing
|
||||
* on-disk sizes.
|
||||
|
@@ -43,7 +43,7 @@ extern bool Debug_deadlocks;
|
||||
/*
|
||||
* Top-level transactions are identified by VirtualTransactionIDs comprising
|
||||
* the BackendId of the backend running the xact, plus a locally-assigned
|
||||
* LocalTransactionId. These are guaranteed unique over the short term,
|
||||
* LocalTransactionId. These are guaranteed unique over the short term,
|
||||
* but will be reused after a database restart; hence they should never
|
||||
* be stored on disk.
|
||||
*
|
||||
@@ -161,7 +161,7 @@ typedef uint16 LOCKMETHODID;
|
||||
|
||||
/*
|
||||
* LOCKTAG is the key information needed to look up a LOCK item in the
|
||||
* lock hashtable. A LOCKTAG value uniquely identifies a lockable object.
|
||||
* lock hashtable. A LOCKTAG value uniquely identifies a lockable object.
|
||||
*
|
||||
* The LockTagType enum defines the different kinds of objects we can lock.
|
||||
* We can handle up to 256 different LockTagTypes.
|
||||
@@ -214,7 +214,7 @@ typedef struct LOCKTAG
|
||||
|
||||
/*
|
||||
* These macros define how we map logical IDs of lockable objects into
|
||||
* the physical fields of LOCKTAG. Use these to set up LOCKTAG values,
|
||||
* the physical fields of LOCKTAG. Use these to set up LOCKTAG values,
|
||||
* rather than accessing the fields directly. Note multiple eval of target!
|
||||
*/
|
||||
#define SET_LOCKTAG_RELATION(locktag,dboid,reloid) \
|
||||
@@ -326,14 +326,14 @@ typedef struct LOCK
|
||||
* a PROCLOCK struct.
|
||||
*
|
||||
* PROCLOCKTAG is the key information needed to look up a PROCLOCK item in the
|
||||
* proclock hashtable. A PROCLOCKTAG value uniquely identifies the combination
|
||||
* proclock hashtable. A PROCLOCKTAG value uniquely identifies the combination
|
||||
* of a lockable object and a holder/waiter for that object. (We can use
|
||||
* pointers here because the PROCLOCKTAG need only be unique for the lifespan
|
||||
* of the PROCLOCK, and it will never outlive the lock or the proc.)
|
||||
*
|
||||
* Internally to a backend, it is possible for the same lock to be held
|
||||
* for different purposes: the backend tracks transaction locks separately
|
||||
* from session locks. However, this is not reflected in the shared-memory
|
||||
* from session locks. However, this is not reflected in the shared-memory
|
||||
* state: we only track which backend(s) hold the lock. This is OK since a
|
||||
* backend can never block itself.
|
||||
*
|
||||
@@ -344,7 +344,7 @@ typedef struct LOCK
|
||||
* as soon as convenient.
|
||||
*
|
||||
* releaseMask is workspace for LockReleaseAll(): it shows the locks due
|
||||
* to be released during the current call. This must only be examined or
|
||||
* to be released during the current call. This must only be examined or
|
||||
* set by the backend owning the PROCLOCK.
|
||||
*
|
||||
* Each PROCLOCK object is linked into lists for both the associated LOCK
|
||||
@@ -377,7 +377,7 @@ typedef struct PROCLOCK
|
||||
|
||||
/*
|
||||
* Each backend also maintains a local hash table with information about each
|
||||
* lock it is currently interested in. In particular the local table counts
|
||||
* lock it is currently interested in. In particular the local table counts
|
||||
* the number of times that lock has been acquired. This allows multiple
|
||||
* requests for the same lock to be executed without additional accesses to
|
||||
* shared memory. We also track the number of lock acquisitions per
|
||||
@@ -422,7 +422,7 @@ typedef struct LOCALLOCK
|
||||
|
||||
/*
|
||||
* This struct holds information passed from lmgr internals to the lock
|
||||
* listing user-level functions (in lockfuncs.c). For each PROCLOCK in
|
||||
* listing user-level functions (in lockfuncs.c). For each PROCLOCK in
|
||||
* the system, copies of the PROCLOCK object and associated PGPROC and
|
||||
* LOCK objects are stored. Note there will often be multiple copies
|
||||
* of the same PGPROC or LOCK --- to detect whether two are the same,
|
||||
|
@@ -6,7 +6,7 @@
|
||||
* PostgreSQL requires counting semaphores (the kind that keep track of
|
||||
* multiple unlock operations, and will allow an equal number of subsequent
|
||||
* lock operations before blocking). The underlying implementation is
|
||||
* not the same on every platform. This file defines the API that must
|
||||
* not the same on every platform. This file defines the API that must
|
||||
* be provided by each port.
|
||||
*
|
||||
*
|
||||
|
@@ -10,7 +10,7 @@
|
||||
*
|
||||
* To simplify life for the SysV implementation, the ID is assumed to
|
||||
* consist of two unsigned long values (these are key and ID in SysV
|
||||
* terms). Other platforms may ignore the second value if they need
|
||||
* terms). Other platforms may ignore the second value if they need
|
||||
* only one ID number.
|
||||
*
|
||||
*
|
||||
|
@@ -20,7 +20,7 @@
|
||||
* been changed to just <offset> as the notion of having multiple pages
|
||||
* within a block has been removed.
|
||||
*
|
||||
* the 'offset' abstraction is somewhat confusing. it is NOT a byte
|
||||
* the 'offset' abstraction is somewhat confusing. it is NOT a byte
|
||||
* offset within the page; instead, it is an offset into the line
|
||||
* pointer array contained on every page that store (heap or index)
|
||||
* tuples.
|
||||
|
@@ -128,7 +128,7 @@ typedef struct SERIALIZABLEXACT
|
||||
* The following types are used to provide an ad hoc list for holding
|
||||
* SERIALIZABLEXACT objects. An HTAB is overkill, since there is no need to
|
||||
* access these by key -- there are direct pointers to these objects where
|
||||
* needed. If a shared memory list is created, these types can probably be
|
||||
* needed. If a shared memory list is created, these types can probably be
|
||||
* eliminated in favor of using the general solution.
|
||||
*/
|
||||
typedef struct PredXactListElementData
|
||||
@@ -311,9 +311,9 @@ typedef struct PREDICATELOCKTAG
|
||||
* The PREDICATELOCK struct represents an individual lock.
|
||||
*
|
||||
* An entry can be created here when the related database object is read, or
|
||||
* by promotion of multiple finer-grained targets. All entries related to a
|
||||
* by promotion of multiple finer-grained targets. All entries related to a
|
||||
* serializable transaction are removed when that serializable transaction is
|
||||
* cleaned up. Entries can also be removed when they are combined into a
|
||||
* cleaned up. Entries can also be removed when they are combined into a
|
||||
* single coarser-grained lock entry.
|
||||
*/
|
||||
typedef struct PREDICATELOCK
|
||||
@@ -384,7 +384,7 @@ typedef struct PredicateLockData
|
||||
|
||||
/*
|
||||
* These macros define how we map logical IDs of lockable objects into the
|
||||
* physical fields of PREDICATELOCKTARGETTAG. Use these to set up values,
|
||||
* physical fields of PREDICATELOCKTARGETTAG. Use these to set up values,
|
||||
* rather than accessing the fields directly. Note multiple eval of target!
|
||||
*/
|
||||
#define SET_PREDICATELOCKTARGETTAG_RELATION(locktag,dboid,reloid) \
|
||||
|
@@ -22,7 +22,7 @@
|
||||
|
||||
/*
|
||||
* Each backend advertises up to PGPROC_MAX_CACHED_SUBXIDS TransactionIds
|
||||
* for non-aborted subtransactions of its current top transaction. These
|
||||
* for non-aborted subtransactions of its current top transaction. These
|
||||
* have to be treated as running XIDs by other backends.
|
||||
*
|
||||
* We also keep track of whether the cache overflowed (ie, the transaction has
|
||||
@@ -53,7 +53,7 @@ struct XidCache
|
||||
* Each backend has a PGPROC struct in shared memory. There is also a list of
|
||||
* currently-unused PGPROC structs that will be reallocated to new backends.
|
||||
*
|
||||
* links: list link for any list the PGPROC is in. When waiting for a lock,
|
||||
* links: list link for any list the PGPROC is in. When waiting for a lock,
|
||||
* the PGPROC is linked into that lock's waitProcs queue. A recycled PGPROC
|
||||
* is linked into ProcGlobal's freeProcs list.
|
||||
*
|
||||
|
@@ -48,7 +48,7 @@ typedef enum ForkNumber
|
||||
* spcNode identifies the tablespace of the relation. It corresponds to
|
||||
* pg_tablespace.oid.
|
||||
*
|
||||
* dbNode identifies the database of the relation. It is zero for
|
||||
* dbNode identifies the database of the relation. It is zero for
|
||||
* "shared" relations (those common to all databases of a cluster).
|
||||
* Nonzero dbNode values correspond to pg_database.oid.
|
||||
*
|
||||
|
@@ -36,7 +36,7 @@
|
||||
*
|
||||
* int TAS(slock_t *lock)
|
||||
* Atomic test-and-set instruction. Attempt to acquire the lock,
|
||||
* but do *not* wait. Returns 0 if successful, nonzero if unable
|
||||
* but do *not* wait. Returns 0 if successful, nonzero if unable
|
||||
* to acquire the lock.
|
||||
*
|
||||
* TAS() is NOT part of the API, and should never be called directly.
|
||||
|
@@ -4,7 +4,7 @@
|
||||
* POSTGRES shared cache invalidation data manager.
|
||||
*
|
||||
* The shared cache invalidation manager is responsible for transmitting
|
||||
* invalidation messages between backends. Any message sent by any backend
|
||||
* invalidation messages between backends. Any message sent by any backend
|
||||
* must be delivered to all already-running backends before it can be
|
||||
* forgotten. (If we run out of space, we instead deliver a "RESET"
|
||||
* message to backends that have fallen too far behind.)
|
||||
|
@@ -31,7 +31,7 @@
|
||||
*
|
||||
* An SMgrRelation may have an "owner", which is just a pointer to it from
|
||||
* somewhere else; smgr.c will clear this pointer if the SMgrRelation is
|
||||
* closed. We use this to avoid dangling pointers from relcache to smgr
|
||||
* closed. We use this to avoid dangling pointers from relcache to smgr
|
||||
* without having to make the smgr explicitly aware of relcache. There
|
||||
* can't be more than one "owner" pointer per SMgrRelation, but that's
|
||||
* all we need.
|
||||
@@ -50,7 +50,7 @@ typedef struct SMgrRelationData
|
||||
/*
|
||||
* These next three fields are not actually used or manipulated by smgr,
|
||||
* except that they are reset to InvalidBlockNumber upon a cache flush
|
||||
* event (in particular, upon truncation of the relation). Higher levels
|
||||
* event (in particular, upon truncation of the relation). Higher levels
|
||||
* store cached state here so that it will be reset when truncation
|
||||
* happens. In all three cases, InvalidBlockNumber means "unknown".
|
||||
*/
|
||||
@@ -62,7 +62,7 @@ typedef struct SMgrRelationData
|
||||
|
||||
/*
|
||||
* Fields below here are intended to be private to smgr.c and its
|
||||
* submodules. Do not touch them from elsewhere.
|
||||
* submodules. Do not touch them from elsewhere.
|
||||
*/
|
||||
int smgr_which; /* storage manager selector */
|
||||
|
||||
|
@@ -29,14 +29,14 @@
|
||||
*
|
||||
* CreateDestReceiver returns a receiver object appropriate to the specified
|
||||
* destination. The executor, as well as utility statements that can return
|
||||
* tuples, are passed the resulting DestReceiver* pointer. Each executor run
|
||||
* tuples, are passed the resulting DestReceiver* pointer. Each executor run
|
||||
* or utility execution calls the receiver's rStartup method, then the
|
||||
* receiveSlot method (zero or more times), then the rShutdown method.
|
||||
* The same receiver object may be re-used multiple times; eventually it is
|
||||
* destroyed by calling its rDestroy method.
|
||||
*
|
||||
* In some cases, receiver objects require additional parameters that must
|
||||
* be passed to them after calling CreateDestReceiver. Since the set of
|
||||
* be passed to them after calling CreateDestReceiver. Since the set of
|
||||
* parameters varies for different receiver types, this is not handled by
|
||||
* this module, but by direct calls from the calling code to receiver type
|
||||
* specific functions.
|
||||
@@ -45,10 +45,10 @@
|
||||
* allocated object (for destination types that require no local state),
|
||||
* in which case rDestroy is a no-op. Alternatively it can be a palloc'd
|
||||
* object that has DestReceiver as its first field and contains additional
|
||||
* fields (see printtup.c for an example). These additional fields are then
|
||||
* fields (see printtup.c for an example). These additional fields are then
|
||||
* accessible to the DestReceiver functions by casting the DestReceiver*
|
||||
* pointer passed to them. The palloc'd object is pfree'd by the rDestroy
|
||||
* method. Note that the caller of CreateDestReceiver should take care to
|
||||
* pointer passed to them. The palloc'd object is pfree'd by the rDestroy
|
||||
* method. Note that the caller of CreateDestReceiver should take care to
|
||||
* do so in a memory context that is long-lived enough for the receiver
|
||||
* object not to disappear while still needed.
|
||||
*
|
||||
@@ -79,7 +79,7 @@
|
||||
* destination. Someday this will probably need to be improved.
|
||||
*
|
||||
* Note: only the values DestNone, DestDebug, DestRemote are legal for the
|
||||
* global variable whereToSendOutput. The other values may be used
|
||||
* global variable whereToSendOutput. The other values may be used
|
||||
* as the destination for individual commands.
|
||||
* ----------------
|
||||
*/
|
||||
|
@@ -24,7 +24,7 @@
|
||||
|
||||
/* ----------------
|
||||
* TCOP_SHOWSTATS controls whether or not buffer and
|
||||
* access method statistics are shown for each query. -cim 2/9/89
|
||||
* access method statistics are shown for each query. -cim 2/9/89
|
||||
* ----------------
|
||||
*/
|
||||
#undef TCOP_SHOWSTATS
|
||||
|
@@ -81,11 +81,11 @@ typedef struct AclItem
|
||||
/*
|
||||
* Definitions for convenient access to Acl (array of AclItem).
|
||||
* These are standard PostgreSQL arrays, but are restricted to have one
|
||||
* dimension and no nulls. We also ignore the lower bound when reading,
|
||||
* dimension and no nulls. We also ignore the lower bound when reading,
|
||||
* and set it to one when writing.
|
||||
*
|
||||
* CAUTION: as of PostgreSQL 7.1, these arrays are toastable (just like all
|
||||
* other array types). Therefore, be careful to detoast them with the
|
||||
* other array types). Therefore, be careful to detoast them with the
|
||||
* macros provided, unless you know for certain that a particular array
|
||||
* can't have been toasted.
|
||||
*/
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user