On Sat, Jun 3, 2017 at 1:20 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Sat, Jun 3, 2017 at 12:10 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> I would have expected that to be handled by separate transition tables >> at different query levels, but evidently it isn't. > > I am wondering if we need to wrap the execution of a modifying CTE in > AfterTriggerBeginQuery() and AfterTriggerEndQuery(). But I'm not sure > where, and it may be a couple of days before I can dig some more.
So, afterTriggers.query_stack is used to handle the reentrancy that results from triggers running further statements that might fire triggers. It isn't used for dealing with extra ModifyTable nodes that can appear in a plan because of wCTEs. Could it also be used for that purpose? I think that would only work if it is the case that each ModifyTable node begin and then runs to completion (ie no interleaving of wCTE execution) and then its AS trigger fires, which I'm not sure about. If that is the case, perhaps AfterTriggerBeginQuery and AfterTriggerEndQuery could become the responsibility of nodeModifyTable.c rather than execMain.c. I haven't tried this yet and it may well be too ambitious at this stage. Other ideas: (1) ban wCTEs that target relations with transition tables in PG10, because we're out of time; (2) find an entirely new way to keep track of the current active transition table(s) to replace the current stack approach, such as including them in the TransitionCaptureState object in the patch that I proposed to fix the nearby inheritance bugs[1]. Stepping back and squinting a bit, both this and the inheritance bug stem from a failure to handle multiple ModifyTable nodes in a plan, but the solutions are approximately opposite: in the inheritance case, the solution I propose is to teach them all to coordinate their tuple capture so that it's in a common format, and in the wCTE case the solution must surely be to ensure that their state is kept separate. The question I'd like to figure out is whether the existing AfterTriggerBeginQuery/AfterTriggerEndQuery stack is the right data structure for that task, considering the control flow when CTEs are executed, which I need to learn more about. Thoughts? [1] https://www.postgresql.org/message-id/flat/CA%2BTgmoZzTBBAsEUh4MazAN7ga%3D8SsMC-Knp-6cetts9yNZUCcg%40mail.gmail.com -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
