On 2015/03/23 2:57, Tom Lane wrote: > Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: >> [ fdw-inh-8.patch ] > > I've committed this with some substantial rearrangements, notably:
> * As I mentioned earlier, I got rid of a few unnecessary restrictions on > foreign tables so as to avoid introducing warts into inheritance behavior. > In particular, we now allow NOT VALID CHECK constraints (and hence ALTER > ... VALIDATE CONSTRAINT), ALTER SET STORAGE, and ALTER SET WITH/WITHOUT > OIDS. These are probably no-ops anyway for foreign tables, though > conceivably an FDW might choose to implement some behavior for STORAGE > or OIDs. I agree with you on this point. However, ISTM there is a bug in handling OIDs on foreign tables; while we now allow for ALTER SET WITH/WITHOUT OIDS, we still don't allow the default_with_oids parameter for foreign tables. I think that since CREATE FOREIGN TABLE should be consistent with ALTER FOREIGN TABLE, we should also allow the parameter for foreign tables. Attached is a patch for that. Best regards, Etsuro Fujita
*** a/src/backend/commands/tablecmds.c --- b/src/backend/commands/tablecmds.c *************** *** 580,586 **** DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId, descriptor = BuildDescForRelation(schema); localHasOids = interpretOidsOption(stmt->options, ! (relkind == RELKIND_RELATION)); descriptor->tdhasoid = (localHasOids || parentOidCount > 0); /* --- 580,587 ---- descriptor = BuildDescForRelation(schema); localHasOids = interpretOidsOption(stmt->options, ! (relkind == RELKIND_RELATION || ! relkind == RELKIND_FOREIGN_TABLE)); descriptor->tdhasoid = (localHasOids || parentOidCount > 0); /*
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
