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

This reverts commit ed29089633 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
This commit is contained in:
Tom Lane 2021-02-07 12:54:08 -05:00
parent 4384eccb15
commit a64aacf152
1 changed files with 0 additions and 6 deletions

View File

@ -504,9 +504,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)
{
@ -528,9 +525,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;
}
/*