postgres.git / summary / log / commit / refs

commit    6f8e393a79e4d28c4b9cbad47b417a63fb4b95fa
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Sun Feb 07 17:54:08 2021 +0000
First released in: 14.0, 9.5.25, 9.6.21, 10.16, 11.11, 12.6, 13.2

    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;
 	}
 
 	/*


[parent: 01e3fe3275af]