Commit 9168793d authored by Michael Paquier's avatar Michael Paquier

Fix comments related to table AMs

Incorrect function names were referenced.  As this fixes some portions
of tableam.h, that is mentioned in the docs as something to look at when
implementing a table AM, backpatch down to 12 where this has been
introduced.

Author: Hironobu Suzuki
Discussion: https://postgr.es/m/8fe6d672-28dd-3f1d-7aed-ac2f6d599d3f@interdb.jp
Backpatch-through: 12
parent a742ecf9
......@@ -1639,9 +1639,9 @@ heap_get_latest_tid(TableScanDesc sscan,
TransactionId priorXmax;
/*
* table_get_latest_tid verified that the passed in tid is valid. Assume
* that t_ctid links are valid however - there shouldn't be invalid ones
* in the table.
* table_tuple_get_latest_tid() verified that the passed in tid is valid.
* Assume that t_ctid links are valid however - there shouldn't be invalid
* ones in the table.
*/
Assert(ItemPointerIsValid(tid));
......
......@@ -1003,12 +1003,12 @@ table_index_fetch_end(struct IndexFetchTableData *scan)
* that tuple. Index AMs can use that to avoid returning that tid in future
* searches.
*
* The difference between this function and table_fetch_row_version is that
* this function returns the currently visible version of a row if the AM
* supports storing multiple row versions reachable via a single index entry
* (like heap's HOT). Whereas table_fetch_row_version only evaluates the
* tuple exactly at `tid`. Outside of index entry ->table tuple lookups,
* table_tuple_fetch_row_version is what's usually needed.
* The difference between this function and table_tuple_fetch_row_version()
* is that this function returns the currently visible version of a row if
* the AM supports storing multiple row versions reachable via a single index
* entry (like heap's HOT). Whereas table_tuple_fetch_row_version() only
* evaluates the tuple exactly at `tid`. Outside of index entry ->table tuple
* lookups, table_tuple_fetch_row_version() is what's usually needed.
*/
static inline bool
table_index_fetch_tuple(struct IndexFetchTableData *scan,
......@@ -1062,8 +1062,9 @@ table_tuple_fetch_row_version(Relation rel,
/*
* Verify that `tid` is a potentially valid tuple identifier. That doesn't
* mean that the pointed to row needs to exist or be visible, but that
* attempting to fetch the row (e.g. with table_get_latest_tid() or
* table_fetch_row_version()) should not error out if called with that tid.
* attempting to fetch the row (e.g. with table_tuple_get_latest_tid() or
* table_tuple_fetch_row_version()) should not error out if called with that
* tid.
*
* `scan` needs to have been started via table_beginscan().
*/
......@@ -1192,8 +1193,8 @@ table_tuple_complete_speculative(Relation rel, TupleTableSlot *slot,
/*
* Insert multiple tuples into a table.
*
* This is like table_insert(), but inserts multiple tuples in one
* operation. That's often faster than calling table_insert() in a loop,
* This is like table_tuple_insert(), but inserts multiple tuples in one
* operation. That's often faster than calling table_tuple_insert() in a loop,
* because e.g. the AM can reduce WAL logging and page locking overhead.
*
* Except for taking `nslots` tuples as input, and an array of TupleTableSlots
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment