pg_dump has historically assumed that default_with_oids affects only plain
tables and not other relkinds. Conceivably we could make it apply to some
newly invented relkind if we did so from the get-go, but changing the
behavior for existing object types will break existing dump scripts.
Add code comments warning about this interaction.
Also, make sure that default_with_oids doesn't cause parse_utilcmd.c to
think that CREATE FOREIGN TABLE will create an OID column. I think this is
only a latent bug right now, since we don't allow UNIQUE/PKEY constraints
in CREATE FOREIGN TABLE, but it's better to be consistent and future-proof.
*/
descriptor = BuildDescForRelation(schema);
+ /*
+ * Notice that we allow OIDs here only for plain tables, even though some
+ * other relkinds can support them. This is necessary because the
+ * default_with_oids GUC must apply only to plain tables and not any other
+ * relkind; doing otherwise would break existing pg_dump files. We could
+ * allow explicit "WITH OIDS" while not allowing default_with_oids to
+ * affect other relkinds, but it would complicate interpretOidsOption().
+ */
localHasOids = interpretOidsOption(stmt->options,
(relkind == RELKIND_RELATION));
descriptor->tdhasoid = (localHasOids || parentOidCount > 0);
cxt.blist = NIL;
cxt.alist = NIL;
cxt.pkey = NULL;
- cxt.hasoids = interpretOidsOption(stmt->options, true);
+
+ /*
+ * Notice that we allow OIDs here only for plain tables, even though
+ * foreign tables also support them. This is necessary because the
+ * default_with_oids GUC must apply only to plain tables and not any other
+ * relkind; doing otherwise would break existing pg_dump files. We could
+ * allow explicit "WITH OIDS" while not allowing default_with_oids to
+ * affect other relkinds, but it would complicate interpretOidsOption(),
+ * and right now there's no WITH OIDS option in CREATE FOREIGN TABLE
+ * anyway.
+ */
+ cxt.hasoids = interpretOidsOption(stmt->options, !cxt.isforeign);
Assert(!stmt->ofTypename || !stmt->inhRelations); /* grammar enforces */