mirror of
https://github.com/postgres/postgres.git
synced 2025-08-25 20:23:07 +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:
@@ -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
|
||||
|
Reference in New Issue
Block a user