From 2a40f65aabe76f3475282ecefeee5b8e35c544ba Mon Sep 17 00:00:00 2001 From: Pavan Deolasee Date: Mon, 21 Nov 2016 12:14:28 +0530 Subject: [PATCH] Do not silently skip FK constraints if loose_constraints are ON. While the git history and comments do not tell us much, it seems this was done to avoid creating FK constraints which may not be correctly enforced when loose_constraints is ON (which allows user to define globally non-enforcable constraints). But instead of wholesale skipping of FKs, it seems we should rather let the users determine which constraints can be enforced and allow them to define them. --- src/backend/parser/parse_utilcmd.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c index 6b9c03503c..a5dbf0e6cd 100644 --- a/src/backend/parser/parse_utilcmd.c +++ b/src/backend/parser/parse_utilcmd.c @@ -2190,25 +2190,6 @@ transformFKConstraints(CreateStmtContext *cxt, if (cxt->fkconstraints == NIL) return; -#ifdef XCP - /* - * If the "loose_constraints" GUC is set, we wholesale avoid creating - * Foreign Keys. Another way is to identify only those unenforceable - * FK constraints and skip over those. However the query string sent to - * the datanodes still contains those FKs and messes up things later. - * This can be handled by re-generating the query string that should be - * passed onto the datanodes, but that's quite a lot of work. - * - * Also supporting some FKs and not some others is also debatable.. - * So we go in for an all-or-nothing approach here - */ - if (loose_constraints) - { - list_free_deep(cxt->fkconstraints); - cxt->fkconstraints = NIL; - return; - } -#endif /* * If CREATE TABLE or adding a column with NULL default, we can safely * skip validation of FK constraints, and nonetheless mark them valid. -- 2.39.5