From 6f8e393a79e4d28c4b9cbad47b417a63fb4b95fa Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 7 Feb 2021 12:54:08 -0500 Subject: [PATCH] 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 --- src/backend/rewrite/rewriteHandler.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c index f91d16aa398..fd63dd7a3bd 100644 --- 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; } /*