RE: Bug in query rewriter - hasModifyingCTE not getting set
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Bug in query rewriter - hasModifyingCTE not getting set |
Дата | |
Msg-id | TYAPR01MB299041D92E7E3FBF52A0257FFE2A9@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | 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
Re: Bug in query rewriter - hasModifyingCTE not getting set |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: