Re: Cleanup/remove/update references to OID column

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleanup/remove/update references to OID column
Date: 2020-04-29 19:46:22
Message-ID: 20200429194622.GA25643@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Few comments seem to have dangling references to the behavior from pre-12 "WITH
OIDS". Maybe varsup.c should get a wider change?

diff --git a/src/backend/access/common/tupdesc.c b/src/backend/access/common/tupdesc.c
index 1e743d7d86..ce84e22cbd 100644
--- a/src/backend/access/common/tupdesc.c
+++ b/src/backend/access/common/tupdesc.c
@@ -786,9 +786,7 @@ TupleDescInitEntryCollation(TupleDesc desc,
*
* Given a relation schema (list of ColumnDef nodes), build a TupleDesc.
*
- * Note: the default assumption is no OIDs; caller may modify the returned
- * TupleDesc if it wants OIDs. Also, tdtypeid will need to be filled in
- * later on.
+ * tdtypeid will need to be filled in later on.
*/
TupleDesc
BuildDescForRelation(List *schema)
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2570e7086a..2f0eab0f53 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -527,8 +527,7 @@ GetNewObjectId(void)
* The first time through this routine after normal postmaster start, the
* counter will be forced up to FirstNormalObjectId. This mechanism
* leaves the OIDs between FirstBootstrapObjectId and FirstNormalObjectId
- * available for automatic assignment during initdb, while ensuring they
- * will never conflict with user-assigned OIDs.
+ * available for automatic assignment during initdb.
*/
if (ShmemVariableCache->nextOid < ((Oid) FirstNormalObjectId))
{
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 262e14ccfb..1ca11960e2 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -4813,7 +4813,7 @@ ATRewriteTables(AlterTableStmt *parsetree, List **wqueue, LOCKMODE lockmode,
continue;

/*
- * If we change column data types or add/remove OIDs, the operation
+ * If we change column data types, the operation
* has to be propagated to tables that use this table's rowtype as a
* column type. tab->newvals will also be non-NULL in the case where
* we're adding a column with a default. We choose to forbid that
@@ -4837,8 +4837,7 @@ ATRewriteTables(AlterTableStmt *parsetree, List **wqueue, LOCKMODE lockmode,

/*
* We only need to rewrite the table if at least one column needs to
- * be recomputed, we are adding/removing the OID column, or we are
- * changing its persistence.
+ * be recomputed, or we are changing its persistence.
*
* There are two reasons for requiring a rewrite when changing
* persistence: on one hand, we need to ensure that the buffers

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-04-29 19:54:43 Re: xid wraparound danger due to INDEX_CLEANUP false
Previous Message Peter Eisentraut 2020-04-29 19:15:13 Re: Add A Glossary