Rephrase references to "time qualification".

Now that the relevant code has, for other reasons, moved out of
tqual.[ch], it seems time to refer to visiblity rather than time
qualification.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645[email protected]

diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml
index d758a4987dc66af647b04a4837d17d2f48b1884b..05102724eadaec60c10867379c2327f076e4ea63 100644 (file)
--- a/doc/src/sgml/indexam.sgml
+++ b/doc/src/sgml/indexam.sgml
@@ -720,7 +720,7 @@ amparallelrescan (IndexScanDesc scan);
    the TIDs of all the tuples it has been told about that match the
    scan keys.  The access method is not involved in
    actually fetching those tuples from the index's parent table, nor in
-   determining whether they pass the scan's time qualification test or other
+   determining whether they pass the scan's visibility test or other
    conditions.
   
 

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index b9862247fb07af01823d29b07858cbffae0db935..4406a69ef266c03fa7d5ea9e6d8482a60a6634a6 100644 (file)
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -1700,7 +1700,7 @@ heap_fetch(Relation relation,
    tuple->t_tableOid = RelationGetRelid(relation);
 
    /*
-    * check time qualification of tuple, then release lock
+    * check tuple visibility, then release lock
     */
    valid = HeapTupleSatisfiesVisibility(tuple, snapshot, buffer);
 
@@ -2020,8 +2020,8 @@ heap_get_latest_tid(Relation relation,
        }
 
        /*
-        * Check time qualification of tuple; if visible, set it as the new
-        * result candidate.
+        * Check tuple visibility; if visible, set it as the new result
+        * candidate.
         */
        valid = HeapTupleSatisfiesVisibility(&tp, snapshot, buffer);
        CheckForSerializableConflictOut(valid, relation, &tp, buffer, snapshot);

diff --git a/src/backend/access/heap/heapam_visibility.c b/src/backend/access/heap/heapam_visibility.c
index 86a99943eb66cb101e944211d8dadc1bd2504411..6cb38f80c688fc013993c22d524e385fad41f20a 100644 (file)
--- a/src/backend/access/heap/heapam_visibility.c
+++ b/src/backend/access/heap/heapam_visibility.c
@@ -1453,8 +1453,8 @@ HeapTupleIsSurelyDead(HeapTuple htup, TransactionId OldestXmin)
  * It's easy to check just infomask bits if the locker is not a multi; but
  * otherwise we need to verify that the updating transaction has not aborted.
  *
- * This function is here because it follows the same time qualification rules
- * laid out at the top of this file.
+ * This function is here because it follows the same visibility rules laid out
+ * at the top of this file.
  */
 bool
 HeapTupleHeaderIsOnlyLocked(HeapTupleHeader tuple)

diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 16903c25f45fce14f5e3951c2ecdf40f5b6eaee7..ba28611d8cc1958fdccfe683260ee1a76f45cd73 100644 (file)
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -5,7 +5,7 @@
  *
  * This is subtle stuff, so pay attention:
  *
- * When a tuple is updated or deleted, our standard time qualification rules
+ * When a tuple is updated or deleted, our standard visibility rules
  * consider that it is *still valid* so long as we are in the same command,
  * ie, until the next CommandCounterIncrement() or transaction commit.
  * (See acces/heap/heapam_visibility.c, and note that system catalogs are