Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes: > [ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably: * I thought that if we were doing this at all, we should go all the way and allow foreign tables to be both inheritance parents and children. * 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 did not like the EXPLAIN changes at all; in the first place they resulted in invalid JSON output (there could be multiple fields of the Update plan object with identical labels), and in the second place it seemed like a bad idea to rely on FDWs to change the behavior of their ExplainModifyTarget functions. I've refactored that so that explain.c remains responsible for getting the grouping right. Also, as I said earlier, it seemed like a good idea to produce subgroups identifying all the target tables not only the foreign ones. * I fooled around with the PlanRowMark changes some more, mainly with the idea that we might soon allow FDWs to use rowmark methods other than ROW_MARK_COPY. The planner now has just one place where a rel's rowmark method is chosen, so as to centralize anything we need to do there. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers