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

Reply via email to