On 12 September 2017 at 11:57, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Tue, Sep 12, 2017 at 11:15 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: > >> But the statement level trigger function can refer to OLD TABLE and >> NEW TABLE, which will contain all the OLD rows and NEW rows >> respectively. So the updated rows of the partitions (including the >> moved ones) need to be captured. So for OLD TABLE, we need to capture >> the deleted row, and for NEW TABLE, we need to capture the inserted >> row. > > Yes, I agree. So in ExecDelete for OLD TABLE we only need to call > ExecARUpdateTriggers which will make the entry in OLD TABLE only if > transition table is there otherwise nothing and I guess this part > already exists in your patch. And, we are also calling > ExecARDeleteTriggers and I guess that is to fire the ROW-LEVEL delete > trigger and that is also fine. What I don't understand is that if > there is no "ROW- LEVEL delete trigger" and there is only a "statement > level delete trigger" with transition table still we are making the > entry in transition table of the delete trigger and that will never be > used.
Hmm, ok, that might be happening, since we are calling ExecARDeleteTriggers() with mtstate->mt_transition_capture non-NULL, and so the deleted tuple gets captured even when there is no UPDATE statement trigger defined, which looks redundant. Will check this. Thanks. > > -- > Regards, > Dilip Kumar > EnterpriseDB: http://www.enterprisedb.com -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers