* 1. In bootstrap mode, we have no choice --- UPDATE wouldn't work.
*
* 2. We could be reindexing pg_class itself, in which case we can't move
- * its pg_class row because CatalogUpdateIndexes might not know about all
- * the indexes yet (see reindex_relation).
+ * its pg_class row because CatalogTupleInsert/CatalogTupleUpdate might
+ * not know about all the indexes yet (see reindex_relation).
*
* 3. Because we execute CREATE INDEX with just share lock on the parent
* rel (to allow concurrent index creations), an ordinary update could
* that the updates do not try to insert index entries into indexes we
* have not processed yet. (When we are trying to recover from corrupted
* indexes, that could easily cause a crash.) We can accomplish this
- * because CatalogUpdateIndexes will use the relcache's index list to know
- * which indexes to update. We just force the index list to be only the
- * stuff we've processed.
+ * because CatalogTupleInsert/CatalogTupleUpdate will use the relcache's
+ * index list to know which indexes to update. We just force the index
+ * list to be only the stuff we've processed.
*
* It is okay to not insert entries into the indexes we have not processed
* yet because all of this is transaction-safe. If we fail partway
adding/deleting caches only requires a recompile.)
Finally, any place your relation gets heap_insert() or
- heap_update() calls, make sure there is a CatalogUpdateIndexes() or
- similar call. The heap_* calls do not update indexes.
-
- bjm 1999/11/22
+ heap_update() calls, use CatalogTupleInsert() or CatalogTupleUpdate()
+ instead, which also update indexes. The heap_* calls do not do that.
*---------------------------------------------------------------------------
*/