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.

diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c
index 6b9c03503c5b4d6dddcc0b0366066bf634a0c35c..a5dbf0e6cdc2b16fe78bc7d99666db05aa9d6c3c 100644 (file)
--- 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.