Revert "Propagate CTE property flags when copying a CTE list into a rule."

This reverts commit ed290896335414c6c069b9ccae1f3dcdd2fac6ba and
equivalent back-branch commits.  The issue is subtler than I thought,
and it's far from new, so just before a release deadline is no time
to be fooling with it.  We'll consider what to do at a bit more
leisure.

Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com

diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
index f91d16aa3989fcf8cb95edfbf7be3516fdf2e39e..fd63dd7a3bdc728e8213b0c4dd804d53ba431a68 100644 (file)
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -511,9 +511,6 @@ rewriteRuleAction(Query *parsetree,
         *
         * This could possibly be fixed by using some sort of internally
         * generated ID, instead of names, to link CTE RTEs to their CTEs.
-        * However, decompiling the results would be quite confusing; note the
-        * merge of hasRecursive flags below, which could change the apparent
-        * semantics of such redundantly-named CTEs.
         */
        foreach(lc, parsetree->cteList)
        {
@@ -535,9 +532,6 @@ rewriteRuleAction(Query *parsetree,
        /* OK, it's safe to combine the CTE lists */
        sub_action->cteList = list_concat(sub_action->cteList,
                                          copyObject(parsetree->cteList));
-       /* ... and don't forget about the associated flags */
-       sub_action->hasRecursive |= parsetree->hasRecursive;
-       sub_action->hasModifyingCTE |= parsetree->hasModifyingCTE;
    }
 
    /*