database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

When WCOs are present, disable direct foreign table modification.

Browse Source 
If the user modifies a view that has CHECK OPTIONs and this gets
translated into a modification to an underlying relation which happens
to be a foreign table, the check options should be enforced.  In the
normal code path, that was happening properly, but it was not working
properly for "direct" modification because the whole operation gets
pushed to the remote side in that case and we never have an option to
enforce the constraint against individual tuples.  Fix by disabling
direct modification when there is a need to enforce CHECK OPTIONs.

Etsuro Fujita, reviewed by Kyotaro Horiguchi and by me.

Discussion: http://postgr.es/m/f8a48f54-6f02-9c8a-5250-9791603171ee@lab.ntt.co.jp
This commit is contained in:
Robert Haas
2017-07-24 15:57:24 -04:00
parent b4af9e3f37
commit 7086be6e36
4 changed files with 93 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
src/backend/optimizer/plan/createplan.c
View File

@ -6500,8 +6500,10 @@ make_modifytable(PlannerInfo *root,
}
/*
* If the target foreign table has any row-level triggers, we can't
* modify the foreign table directly.
* Try to modify the foreign table directly if (1) the FDW provides
* callback functions needed for that, (2) there are no row-level
* triggers on the foreign table, and (3) there are no WITH CHECK
* OPTIONs from parent views.
*/
direct_modify = false;
if (fdwroutine != NULL &&
@ -6509,6 +6511,7 @@ make_modifytable(PlannerInfo *root,
fdwroutine->BeginDirectModify != NULL &&
fdwroutine->IterateDirectModify != NULL &&
fdwroutine->EndDirectModify != NULL &&
withCheckOptionLists == NIL &&
!has_row_triggers(root, rti, operation))
direct_modify = fdwroutine->PlanDirectModify(root, node, rti, i);
if (direct_modify)