RE: Bug in query rewriter - hasModifyingCTE not getting set - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Bug in query rewriter - hasModifyingCTE not getting set
Date
Msg-id TYAPR01MB299041D92E7E3FBF52A0257FFE2A9@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Bug in query rewriter - hasModifyingCTE not getting set  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug in query rewriter - hasModifyingCTE not getting set  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Bug in query rewriter - hasModifyingCTE not getting set  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
From: Tom Lane <tgl@sss.pgh.pa.us>
> I think either the bit about rule_action is unnecessary, or most of
> the code immediately above this is wrong, because it's only updating
> flags in sub_action.  Why do you think it's necessary to change
> rule_action in addition to sub_action?

Finally, I think I've understood what you meant.  Yes, the current code seems to be wrong.  rule_action is different
fromsub_action only when the rule action (the query specified in CREATE RULE) is INSERT SELECT.  In that case,
rule_actionpoints to the entire INSERT SELECT, while sub_action points to the SELECT part.  So, we should add the CTE
listand set hasModifyingCTE/hasRecursive flags in rule_action. 


> Hm.  So after looking at this more, the problem is that the rewrite
> is producing something equivalent to
>
> INSERT INTO bug6051_2
> (WITH t1 AS (DELETE FROM bug6051 RETURNING *) SELECT * FROM t1);

Yes.  In this case, the WITH clause must be put before INSERT.

The attached patch is based on your version.  It includes cosmetic changes to use = instead of |= for boolean variable
assignments. make check passed.  Also, Greg-san's original failed test case succeeded.  I confirmed that the
hasModifyingCTEof the top-level rewritten query is set to true now by looking at the output of debug_print_rewritten
anddebug_print_plan. 


Regards
Takayuki Tsunakawa


Attachment

pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: Alias collision in `refresh materialized view concurrently`
Next
From: Andrew Dunstan
Date:
Subject: Re: multi-install PostgresNode fails with older postgres versions