default_with_oids

Definition PG 11 manual

This controls whether CREATE TABLE and CREATE TABLE AS include an OID column in newly-created tables, if neither WITH OIDS nor WITHOUT OIDS is specified. It also determines whether OIDs will be included in tables created by SELECT INTO. The parameter is off by default; in PostgreSQL 8.0 and earlier, it was on by default.

The use of OIDs in user tables is considered deprecated, so most installations should leave this variable disabled. Applications that require OIDs for a particular table should specify WITH OIDS when creating the table. This variable can be enabled for compatibility with old applications that do not follow this behavior.

How it works

Create new tables with OIDs by default. The parameter still exists in PG11 and is no longer recognized from PG12. PostgreSQL 12 removed user-table OIDs; use an identity column, sequence, or another explicit key instead.

While present, this changed CREATE TABLE without an explicit WITH/WITHOUT OIDS clause. Table OIDs were neither a durable application key nor guaranteed unique, and the feature disappeared with user-table OIDs in PostgreSQL 12.

Before upgrading, inspect lo_compat_privileges, operator_precedence_warning, synchronize_seqscans, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG12 or later.

Operational considerations

Continuing to emit unknown parameter default_with_oids on PG12+.

Deleting only the setting name without migrating dependent application behavior.

Assuming the historical default equals the replacement mechanism's default.

Missing stale entries in ALTER SYSTEM, role/database settings, or automation templates.

Workload guidance

OLAP: Use the same migration path as OLTP, and also verify long batches, standbys, or large-object/extension workflows; removal of the old switch does not promise identical legacy behavior.

OLTP: Do not tune or continue emitting default_with_oids on PG12+. PostgreSQL 12 removed user-table OIDs; use an identity column, sequence, or another explicit key instead. Scan every configuration layer and regression-test the application before upgrade.

SMALL: Delete the obsolete setting and adopt the supported replacement directly; do not emulate legacy behavior in scripts without a demonstrated compatibility requirement.