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 ba6f8a0507253673221c8bfbd16e4d16a8de1381..0672f497c6b35b82a50530375c99d73bcb0eefdf 100644 (file)
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -536,9 +536,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)
        {
@@ -560,9 +557,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;
    }
 
    /*

diff --git a/src/test/regress/expected/with.out b/src/test/regress/expected/with.out
index 5e4ea29243bd5d9678089171a9315a195e40c700..c519a61c4fe794f7d399a0746e7c32a481b0954b 100644 (file)
--- a/src/test/regress/expected/with.out
+++ b/src/test/regress/expected/with.out
@@ -2277,33 +2277,6 @@ SELECT * FROM bug6051_2;
  3
 (3 rows)
 
--- silly example to verify that hasModifyingCTE flag is propagated
-CREATE TEMP TABLE bug6051_3 AS
-  select a from generate_series(11,13) as a;
-CREATE RULE bug6051_3_ins AS ON INSERT TO bug6051_3 DO INSTEAD
-  SELECT i FROM bug6051_2;
-BEGIN; SET LOCAL force_parallel_mode = on;
-WITH t1 AS ( DELETE FROM bug6051_3 RETURNING * )
-  INSERT INTO bug6051_3 SELECT * FROM t1;
- i 
----
- 1
- 2
- 3
- 1
- 2
- 3
- 1
- 2
- 3
-(9 rows)
-
-COMMIT;
-SELECT * FROM bug6051_3;
- a 
----
-(0 rows)
-
 -- a truly recursive CTE in the same list
 WITH RECURSIVE t(a) AS (
    SELECT 0

diff --git a/src/test/regress/sql/with.sql b/src/test/regress/sql/with.sql
index 0ffa44afa7ad3fdbcb8e55198e3da06217cd402b..f4ba0d8e39942043400c94987048a79e37b54832 100644 (file)
--- a/src/test/regress/sql/with.sql
+++ b/src/test/regress/sql/with.sql
@@ -1070,22 +1070,6 @@ INSERT INTO bug6051 SELECT * FROM t1;
 SELECT * FROM bug6051;
 SELECT * FROM bug6051_2;
 
--- silly example to verify that hasModifyingCTE flag is propagated
-CREATE TEMP TABLE bug6051_3 AS
-  select a from generate_series(11,13) as a;
-
-CREATE RULE bug6051_3_ins AS ON INSERT TO bug6051_3 DO INSTEAD
-  SELECT i FROM bug6051_2;
-
-BEGIN; SET LOCAL force_parallel_mode = on;
-
-WITH t1 AS ( DELETE FROM bug6051_3 RETURNING * )
-  INSERT INTO bug6051_3 SELECT * FROM t1;
-
-COMMIT;
-
-SELECT * FROM bug6051_3;
-
 -- a truly recursive CTE in the same list
 WITH RECURSIVE t(a) AS (
    SELECT 0