Skip to content

Commit a64aacf

Browse files
committed
Revert "Propagate CTE property flags when copying a CTE list into a rule."
This reverts commit ed29089 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
1 parent 4384ecc commit a64aacf

File tree

1 file changed

+0
-6
lines changed

1 file changed

+0
-6
lines changed

src/backend/rewrite/rewriteHandler.c

Lines changed: 0 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -504,9 +504,6 @@ rewriteRuleAction(Query *parsetree,
504504
*
505505
* This could possibly be fixed by using some sort of internally
506506
* generated ID, instead of names, to link CTE RTEs to their CTEs.
507-
* However, decompiling the results would be quite confusing; note the
508-
* merge of hasRecursive flags below, which could change the apparent
509-
* semantics of such redundantly-named CTEs.
510507
*/
511508
foreach(lc, parsetree->cteList)
512509
{
@@ -528,9 +525,6 @@ rewriteRuleAction(Query *parsetree,
528525
/* OK, it's safe to combine the CTE lists */
529526
sub_action->cteList = list_concat(sub_action->cteList,
530527
copyObject(parsetree->cteList));
531-
/* ... and don't forget about the associated flags */
532-
sub_action->hasRecursive |= parsetree->hasRecursive;
533-
sub_action->hasModifyingCTE |= parsetree->hasModifyingCTE;
534528
}
535529

536530
/*

0 commit comments

Comments
 (0)