default_with_oids

default_with_oids — Create new tables with OIDs by default. Observed in PG9.0–11; its last measured boot default is off in PG11, with user context. It was removed in PG12.

Note

Fact — official short description: “Create new tables with OIDs by default.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueVersion and Platform Compatibility / Previous PostgreSQL Versions: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–11
Removed in	PG12
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–11	`off`	—	off

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
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.
Small nodes	Delete the obsolete setting and adopt the supported replacement directly; do not emulate legacy behavior in scripts without a demonstrated compatibility requirement.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG11; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–11 unmodified; OLAP: PG9.0–11 unmodified; CRIT: PG9.0–11 unmodified; TINY: PG9.0–11 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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.

lo_compat_privileges · operator_precedence_warning · synchronize_seqscans · standard_conforming_strings · array_nulls · backslash_quote