From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: Daniel Verite <daniel@manitou-mail.org>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Cleanup/remove/update references to OID column
Date: Wed, 29 Apr 2020 14:46:22 -0500
Message-ID: <20200429194622.GA25643@telsasoft.com> (raw)
In-Reply-To: <20190701155932.GA22866@telsasoft.com>
References: <20190408002847.GA904@telsasoft.com>
<da5a314d-f92d-47ef-b005-8451f26de0f2@manitou-mail.org>
<20190410165917.GD10080@telsasoft.com>
<20190418002347.rlqmypv5prlpl2bg@alap3.anarazel.de>
<20190418004219.GJ2854@telsasoft.com>
<20190418005115.r4mat75wvlski3ij@alap3.anarazel.de>
<20190508190557.GD3925@telsasoft.com>
<20190701155932.GA22866@telsasoft.com>
Few comments seem to have dangling references to the behavior from pre-12 "WITH
OIDS". Maybe varsup.c should get a wider change?
inline patch 1: src/backend/access/common/tupdesc.c, src/backend/access/transam/varsup.c, src/backend/commands/tablecmds.c (+4/-8 lines) download inline-1.patchdiff --git a/src/backend/access/common/tupdesc.c b/src/backend/access/common/tupdesc.cindex 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.cindex 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.cindex 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, andres@anarazel.de, daniel@manitou-mail.org, pgsql-hackers@lists.postgresql.org
Subject: Re: Cleanup/remove/update references to OID column
In-Reply-To: <20200429194622.GA25643@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox