Re: Mishandling of WCO constraints in direct foreign table modification

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2017-07-21T10:21:42Z
Lists: pgsql-hackers
On 2017/07/21 17:18, Kyotaro HORIGUCHI wrote:
> At Fri, 21 Jul 2017 12:00:03 +0900, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote in <15aa9936-9bd8-c9e3-7ca1-3948610734b4@lab.ntt.co.jp>
>> Attached is the second version which updated docs in postgres-fdw.sgml
>> as well.
> 
> !    no local joins for the query, no row-level local <literal>BEFORE</> or
> !    <literal>AFTER</> triggers on the target table, and no
> !    <literal>CHECK OPTION</> constraints from parent views.
> !    In <command>UPDATE</>,
> 
> Might be a silly question, is CHECK OPTION a "constraint"?

I mean constraints derived from WITH CHECK OPTIONs specified for parent 
views.  We use the words "WITH CHECK OPTION constraints" in comments in 
nodeModifyTable.c, so the expression "CHECK OPTION constrains" doesn't 
sound not that bad to me.  (I used "CHECK OPTION", not "WITH CHECK 
OPTION", because we use "CHECK OPTION" a lot more in the documentation 
than "WITH CHECK OPTION".)

Best regards,
Etsuro Fujita



Commits

  1. When WCOs are present, disable direct foreign table modification.