database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-17 17:02:08 +03:00
Code Activity

Add comments warning against generalizing default_with_oids.

Browse Source 
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.
This commit is contained in:
Tom Lane
2015-04-25 21:37:39 -04:00
parent 04f1542d39
commit 0bd11d9711
2 changed files with 20 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/commands/tablecmds.c
View File

@ -579,6 +579,14 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
*/
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);